7. Chapter 6 - Conclusion and Next Steps

7.1. What Has Been Built

This document has adapted the core functionality and authentication of the [RdvMedecins] application from the original 2014 document to current technologies:

a complete [NestJS] server (included with this document, installed and tested in Chapter 2, but whose code is not covered here), exposing the same 11 JSON business routes as the original Spring 4 server, on the same port (8080), all of which are now protected by a JWT token;
an authentication layer ([@nestjs/passport] + [@nestjs/jwt]): login/password authentication (POST /login), a signed token presented with each subsequent request, and role-based access control ([@Roles]('ADMIN') + [RolesGuard]) on the two routes that modify data;
a [Flutter] client (widgets [Material], package [provider]) offering the same features as the original AngularJS 1.x client—selecting a doctor and a date, viewing the calendar, booking and canceling an appointment—supplemented by a login screen, a persistent session ([shared_preferences]), an interface tailored to the logged-in user’s role (booking buttons hidden for the USER role), and the ability to switch the interface between French and English ([TranslationsService], reimplemented without a third-party library).

The core of the database has not changed (same tables [doctors/clients/slots/appointments], same constraints), except for the addition of the table [users]; nor has the general layered architecture—only the tools that implement it have been updated.

Two intentional differences from the original document’s authentication, implemented by the delivered server (see Chapter 2): a JWT token rather than the HTTP Basic header sent with each request, and a single [role] column per user rather than a many-to-many relationship across three tables. A third difference—this one functional—was deliberately chosen for this port: the USER role can now view calendars (read-only), whereas in the original it served only to illustrate a total denial of access.

7.2. What Remains Outside the Scope or to Be Ported

Beyond the above, the original document covered three additional topics—one of which has now been addressed, another deliberately left out, and the third deferred to a later stage:

7.2.1. French/English internationalization—addressed in this document

The original document proposed switching the interface between French and English using the [angular-translate] library. This port implements this functionality using [TranslationsService] (see Chapter 4), written specifically for this document rather than delegated to a third-party plugin: the fr.json/en.json dictionaries, embedded in the application (and no longer served by a web server), are loaded via [rootBundle.loadString(...)]. Like [angular-translate] and [vue-i18n] before it, [TranslationsService] allows you to switch languages on the fly without reloading the application—a behavior faithful to that of the original document.

7.2.2. The client’s “debug” mode—deliberately excluded from the scope

The original document included a technical display mode, activatable from the interface, that provided access to the raw model ($scope AngularJS 1.x) of the current view—a useful feature in 2014, when the development tools available for inspecting an AngularJS application were still limited. This port does not rebuild it: the current [Flutter] development tools ([Flutter] DevTools, usable on all three targets—mobile, desktop, web) now offer, apart from the application itself, a much more comprehensive inspection of the widget tree, their state, and their properties than a custom debugging panel reintegrated into the interface would provide. Adding such a panel would amount to creating a lesser version of a tool already provided by the ecosystem—this decision is therefore final, not merely a postponement.

7.2.3. Artificial network delay—postponed

The original document allowed setting an artificial delay before each server response, to observe the interface’s behavior on a slow network (loading indicators, temporary button deactivation, etc.). This feature does not yet have an equivalent in this port.

7.3. A note on the methodology used in this document

This document was written by systematically relying on the actual executed code: every server path was tested (including authentication scenarios: successful/failed login, access without a token, access with the wrong role); the [Flutter] client (Chapter 4), on the other hand, was reviewed and verified line by line rather than run by Claude—the environment that produced this document does not have access to a machine capable of running [Flutter] (mobile, desktop, or web), unlike the previous web clients in this course, which can be run directly in an automated [Chromium] browser. The screenshots of the client in Chapters 4 and 5 (web, Windows desktop, Android emulator) were taken by the author on his own machine.

7.4. To take it further right now

While waiting for the next steps in this port, the server and client included with this document provide a ready-to-use foundation for you to experiment on your own:

add a new doctor or a new patient (currently, this is done only by modifying the SQL script—a /addDoctor route, also protected by [@Roles]('ADMIN'), could be a first exercise);
add a third role, or a user with multiple roles—an opportunity to assess, in very concrete terms, the cost of abandoning the single-column simplification provided by [role] (see Chapter 2);
modify the client’s presentation (colors, layout) without changing the server—a good way to verify that the client’s layered architecture works as intended;
Review the README file for each folder in the delivered server and client: each explains, in its context, the role of the files it contains.