Quelle technologie pour créer une webapp à partir d’API REST ?

Salut les agrumes,

J’ai un projet qui se découpe en plusieurs parties : une API REST, une application web pour l’utiliser, et peut-être une application mobile.

L’API REST elle-même est OK, il n’y a rien à toucher dessus.

Par contre je me pose des questions existentielles quant à la technologie que je peux utiliser pour la webapp, d’où ce post. Actuellement, sur quelle technologie/framework partiriez-vous avec les contraintes suivantes ?

• Réalisation d’une application web, très dynamique (pas de génération de pages par un serveur).
• Toutes les données proviennent d’une API REST qui renvoie du JSON.
• Découplage fort entre l’API et les frontaux : je ne veux pas avoir à modifier l’API pour les besoins spécifiques de l’affichage.
• L’authentification se fait avec OpenID Connect, donc il faut une solution qui gère ça facilement ; ou qui permet d’intégrer keycloak.js.
• La technologie/framework doit être un minimum stable et suivie : le but est que le projet vive, pas de tout refaire dans 6 mois à cause d’une version qui casse tout ou parce que le framework est mort.
• Pas de framework de composants, je veux pouvoir générer exactement le HTML que je veux et n’utiliser que du CSS custom.
• Idéalement le framework n’est pas trop lourd (en dev et au runetime produit), mais ce point n’est pas indispensable.

Dans mon esprit j’étais parti sur du VueJS 3, mais comme je ne suis pas à jour sur les technos front, je passe peut-être à côté de quelque chose de plus efficace.

Merci d’avance pour vos idées !

En terme de learning curve (du plus facile au plus long) je pense qu’on peut classer les frameworks js dans cet ordre : Vujs3 est pas mal, sinon React ou Angular tout dépend du temps que tu es prêt à investir dans l’apprentissage.

Peut-être que svelte permet de le faire mais je n’ai pas dxp

Non, VueJS me semble très adapté. Tu as aussi Svelte sinon, qui est un framework, une prochaine version, rétro-compatible avec la version courante, va sortir prochainement. Si tu connais déjà VueJS alors prend VueJS.

Je ne connais pas keycloak.js par-contre. Je n’ai aucun doute sur le fait que tu puisses l’utiliser avec VueJS / Svelte / Ember ou même Alpine.JS.

D’ailleurs Alpine.JS est peut-être adapté mais rentre dans la catégorie, trop récent et trop petit pour être vraiment stable.

A noter qu’il existe également preact comme microframework js

Vue.js fait bien le boulot, il y a maintenant une nouvelle façon de l’utiliser (composition API) qui ne devait pas exister du temps de ton billet https://zestedesavoir.com/billets/2895/8-mois-avec-javascript-es6-et-vue-js/, mais l’option API existe toujours.

Pour utiliser keycloak et vu3 au boulot c’est un bon système, notamment avec axios pour faire les requêtes rest et pinia pour les store globaux.

Par contre pour avoir appris les deux, je trouve la learning curve de React plus douce que celle de vue où pas mal de choses contrintuitives arrivent notamment entre les ref/states et les props.

Pour ceux qui savent pas, keycloak est un service d’authentification basé principalement sur OpenID et implémenté en java. Il implémente déjà tout ce qu’il faut pour gérer des users, lier des IDP publics (github, twitter…) ou d’entreprise (google workspace, microsoft Azure AD/Entra, tous les IDP SAML…) et customiser les flux de création d’utilisateur. C’est assez complet comme techno.

Je trouve la courbe d’apprentissage de Svelte plus plate que celle de VueJS également.

Mais du coup, si tu connais déjà VueJS, j’aurais du mal à justifier l’apprentissage d’une nouvelle techno sachant qu’au final, le résultat est globalement le même.

Si c’est pas pur curiousité pourquoi pas mais alors autant partir sur une technologie le plus différente possible.

Merci tout le monde pour les réponses !

Si je résume, Vue est toujours d’actualité et est une solution correcte dans mon cas ? Si oui, c’est parfait, d’autant que j’avais déjà regardé les nouveautés de Vue 3.

C’est totalement une solution qui fonctionne et qui te permettra de faire tout ce que tu veux.

Ceci dit je te conseille vraiment de passer à vue3 et d’utiliser leur nouvelle syntaxe (composition API).

Oui, le but n’est pas d’utiliser de vieilles technos, au contraire.

Pour les applications dynamiques, j’ai l’impression que la nouvelle tendance est plutôt du côté de l'Universal Rendering (souvent nommé Server Side Rendering à tort, ce qui peut porter à confusion). L’idée est de générer la page côté serveur lors de la requête initiale, puis de générer les pages suivantes côté client.

Cela permet de bénéficier des avantages des deux modes.

• Lors de la requête initiale : chargement de la page plus rapide (meilleur TTI), possibilité de caching, suppression des problèmes liés au SEO, etc.
• Lors de la navigation vers les autres pages : requêtes plus légères (voire inexistantes), pas besoin de regénérer toute la page, pas de perte de l’interactivité, etc.

Il est tout à fait possible de totalement découpler le "serveur de rendering" et le serveur de l’API REST. Il existe notamment Nuxt, un framework qui implémente justement cette solution avec Vue.js, qui a l’avantage d’être assez rapide et léger sans être trop complexe.

Je suis assez d’accord avec @Olybri, même si c’est même un peu dépassé.
Dernièrement, ce que je vois souvens c’est l’hybride SSR/CSR, ce qu’on appelle de l’ISR, Incremental Static Regeneration.

Par-contre, SpaceFox voulait explicitement du statique (SSG).

PS: J’ai lu trop vite. Ce qu’il/elle appelle SSR est en fait de l’ISR.

Merci pour ces infos, même si ça n’est absolument pas ce que je cherche.

Mon projet est extrêmement dynamique (c’est 100% une application, il n’y a pas de notion de « page » à proprement parler), et n’a aucune problématique de SEO : tout est privé, et intégralement personnalisé par utilisateur.

En conséquence, je n’ai donc aucun intérêt à rendre du HTML côté serveur, au contraire. Ça me permet d’avoir un seul serveur dynamique côté back (les API) et des transferts réseau optimaux : le premier transfert n’est pas énorme (surtout que je n’ai pas de framework CSS qui me génère un fichier monstrueux et m’impose de rendre mon HTML obèse) ; les transferts suivants à l’usage sont bien plus importants et sont optimaux (JSON avec juste les données nécessaires).

Je n’utilisera donc pas Nuxt, qui ne semble pas correspondre à mon besoin. En fait je suis plutôt dans la démarche inverse, éviter d’utiliser autant que possible ce genre de framework de frameworks qui rajoute beaucoup de magie au détriment de la maitrise de l’outil.

Merci quand même pour m’avoir fait découvrir ces techniques de rendu.

Effectivement, pour une application privée sans notion de pages, pas besoin de Nuxt, Vue.js suffira.

Cela dit, Nuxt n’est pas vraiment un "framework de framework avec de la magie" (même si moi-même j’étais sceptique au début). Il s’agit simplement d’un outil qui regroupe Vue.js, Vite, les Single-File Components (SFC), un routeur, et la gestion du SSR et du cache.

Vue.js en lui-même n’est pas vraiment un framework, c’est plutôt une simple librairie de génération de HTML qui n’impose aucune structure. D’ailleurs pour la plupart des projets Vue, généralement on installe également Vite, le compilateur de SFC, et un routeur (voire encore un store du genre Pinia), le tout en s’imposant sa propre structure de fichiers, ce qui au final donne des projets assez semblables à un projet Nuxt.

SSR, CSR, SSG, ISR… beaucoup de termes qui tournent sur le web et dont les définitions sont variées, mais au final il n’y a que deux possibilités : soit le HTML est généré par le serveur, soit il est généré par le client. Quant à la notion de static dans SSG et ISR, il s’agit simplement de HTML pré-généré côté serveur puis gardé en cache selon diverses règles.

Personellement, j’ai l’habitude d’utiliser le terme Universal Rendering pour parler de la combinaison SSR (première requête) et CSR (navigation), indépendamment de la pré-génération ou de mise en cache. Certains parlent encore d'Hybrid Rendering pour désigner les frameworks qui supporte un mode de rendu différents pour chaque page.