EventPassSaaS reservation de billet d'évenements
Un client qui réserve un billet parle JSON. Un outil d'audit qui exporte les logs parle XML. Sur EventPass, les deux frappent le même backend NestJS.
EventPass est une plateforme de billetterie événementielle développée à trois dans le cadre du Master Web Services. Une API NestJS, un front React, PostgreSQL derrière, le tout orchestré par Docker Compose. Code sur GitHub.
Un seul backend, deux protocoles
L'idée structurante du projet : le backend joue le rôle de bus de services. Côté front-office, une API REST classique (25 routes, JWT, Swagger) sert l'application React. Côté back-office, un endpoint SOAP expose cinq opérations métier dédiées au reporting et à la gouvernance, contractualisées par un WSDL.
Les deux protocoles tapent dans les mêmes services NestJS, donc dans le même TypeORM, donc dans la même base. Pas de duplication de logique métier, juste deux surfaces d'exposition différentes pour deux profils d'usage différents.
Pourquoi pas tout en REST
La question s'est posée. La réponse tient en une ligne : tout le monde n'a pas besoin de la même rigueur contractuelle.
REST (front-office) | SOAP (back-office) | |
|---|---|---|
Format | JSON | XML + WSDL |
Validation | Souple, via Swagger | Stricte, schéma XSD |
Gouvernance | Convention | Contrat immuable |
Cible | App client | Reporting, audit |
Pour un utilisateur qui réserve un billet, la latence prime, et JSON suffit. Pour un export d'audit qui devra être consommé dans cinq ans par un outil qu'on ne connaît pas encore, le WSDL agit comme un contrat figé que ni le client ni le serveur ne peut casser sans s'en rendre compte.
La stack technique
Ce que j'en ai retenu
Deux choses, brièvement.
Faire cohabiter REST et SOAP dans le même processus n'est pas une prouesse, c'est juste une discipline d'architecture. NestJS gère les deux nativement, le vrai travail consiste à séparer proprement les controllers et à ne jamais dupliquer la logique entre les deux surfaces.
SOAP a mauvaise réputation, à tort dans certains contextes. Pour du reporting financier et de l'audit, le WSDL apporte une garantie contractuelle que Swagger ne donne pas. Le coût d'écriture est plus élevé, le bénéfice se paie sur la durée.
Gallerie