7. Chapter 6—Conclusion and Next Steps

7.1. What Has Been Built

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

a complete [NestJS] server (entities [TypeORM], DAO, business layer, web layer), exposing the same 11 business routes JSON as the original Spring 4 server, on the same port (8080), all now protected by a token JWT;
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 client [Angular] (standalone components, signals) offering the same functionality as the original client AngularJS 1.x—selecting a doctor and a date, viewing the calendar, booking and canceling an appointment - supplemented with a login screen, a persistent session (localStorage), a Bootstrap interface that adapts to the logged-in user’s role (booking buttons hidden for role USER), and the ability to switch the interface between French and English ([@ngx-translate/core] + [@ngx-translate/http-loader]).

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

Two intentional differences from the authentication mechanism in the original document, documented in detail in Chapter 3: a JWT token instead of the HTTP Basic header sent with each request, and a single [role] column per user instead of 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 two 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 localization—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 its equivalent in the current [Angular] ecosystem, [@ngx-translate/core] (accompanied by [@ngx-translate/http-loader], which loads the dictionaries fr.json/en.json with HTTP from the public/i18n folder)—see Chapter 5. @angular/localize, the other possible solution, was ruled out: it requires separate compilation per language, whereas ngx-translate allows you to switch languages on the fly without reloading the page—a behavior closer 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, which 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 a AngularJS application were still limited. This port does not recreate it: current [Angular] development tools ([Angular] DevTools, official browser extension) now offer, outside of the application itself, a much more comprehensive inspection of components, their signals, and their inputs/outputs 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. An artificial network delay—postponed

The original document allowed you to set an artificial delay before each server response, in order to observe the interface’s behavior on a slow network (loading indicators, temporary deactivation of buttons, 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 code that was actually executed: every server path was tested (including authentication scenarios: successful/failed login, access without a token, access with the wrong role), and every client screenshot (Chapter 5) was obtained by interacting with the actual running application—an automatically controlled Chromium browser using demo data from the provided SQL script. This approach also revealed, during the preparation of this document, a specific issue regarding the use of [TypeORM] with calculated columns ([@RelationId])—which was reported and corrected in Chapter 3, directly in the delivered code. This requirement also explains why Postman screenshots are not included in this document: rather than simulating them, it seemed preferable to leave this step to the document’s author, who can create them directly from their own workstation.

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 can only be done by modifying the SQL script—a route /ajouterMedecin, also protected by [@Roles]('ADMIN'), could be a good 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 [role] (see Chapter 3);
modify the client’s presentation (colors, layout) without changing the server—a good way to verify that the client’s layered architecture works as advertised;
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.