7. Chapter 6 - Conclusion and Next Steps

7.1. What Has Been Built

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

a complete [NestJS] server ([TypeORM] entities, 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 [Vue.js] (Composition API, setup script) 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 by a login screen, a persistent session (localStorage), a Bootstrap interface that adapts to the logged-in user’s role (booking buttons hidden for a specific role USER), and the ability to switch the interface between French and English ([vue-i18n]).

The core of the database has not changed (same tables [medecins/clients/creneaux/rv], 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.

There are two intentional differences from the authentication process in the original document, documented in detail in Chapter 3: 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 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 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 its equivalent in the current [Vue.js] ecosystem, [vue-i18n] (whose dictionaries fr.json/en.json are loaded by HTTP from the [public/i18n/] folder via a small loading function written for this port, since there is no official HTTP plugin equivalent to the one used on the React side) - See Chapter 5. Like [angular-translate] before it, [vue-i18n] allows you to switch languages on the fly, without reloading the page—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, 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 [Vue.js] development tools ([Vue.js] DevTools, official browser extension) now offer, outside of the application itself, a much more comprehensive inspection of components, their state (hooks), and their props 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 based entirely 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 named /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 provided by [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.