On entend fréquemment que les Single Page Applications (SPA) coûtent cher. Certaines entreprises le découvrent à leurs dépends et se tournent vers d’autres types d’applications Web malgré les sommes considérables déjà engagées dans la mise en place d’une SPA.
En un sens, c’est vrai, les SPA coûtent cher. Nous allons tenter d’identifier les éléments qui constituent leur coût. Mais ce faisant, voyons également quels services elles rendent que les applications “classiques” ne rendent pas, afin de formuler le problème plus finement. Cela est d’autant plus important que les SPA sont entourées d’un effet de mode qui tend à faire des uns les défenseurs, des autres les pourfendeurs de ce qui n’est jamais qu’une technologie parmi d’autres.
Définition et comparaison
Dans une architecture Web traditionnelle, l’utilisateur se sert de son navigateur comme client (dit client “léger”) pour visualiser une page composée principalement de code HTML généré côté serveur par du code Java, .NET, Ruby, Python ou PHP, cette liste ne prétendant pas être exhaustive. Les actions de l’utilisateur sur la page sont à l’origine de requêtes à destination du serveur qui, en réponse, va renvoyer à chaque fois une nouvelle page comptant pour quelques centaines de Ko. Pour cette raison, et même si le terme est peu répandu, nous pourrions parler de Multiple Pages Applications (MPA).
Au contraire, une Single Page Application est constituée majoritairement de code JavaScript enveloppé dans une coquille de code HTML. Ce code JavaScript, qui pèse fréquemment plusieurs dizaines de Mo, sera récupéré du serveur en une fois, au chargement de la page. Par la suite, il aura la responsabilité de réagir aux actions de l’utilisateur, d’initier les requêtes XHR asynchrones visant à récupérer des données du serveur et de les intégrer dans la page courante sans que celle-ci ne soit jamais rechargée. Il en résulte une expérience de navigation fluide et une faible consommation de bande passante une fois passé le chargement initial.
Une SPA nécessite la mise en place d’une API pouvant être interrogée pour lire ou agir sur les entités métier de l’application. Les API sont fréquemment structurées selon une architecture REST ou GraphQL et les données sont échangées le plus souvent au format JSON, parfois au format Protobuf lorsque les volumes sont plus importants.
Des Single Page Applications grand public telles que Gmail, Twitter ou Netflix nous ont habitués à une expérience de navigation entièrement nouvelle avec des fonctionnalités riches, complexes à mettre en œuvre mais qui sont devenues la norme : scroll infini, annulation des actions, drag-and-drop, notifications, travail hors connexion et quantité d’interactions qui, toutes, contribuent à amoindrir la frontière séparant les applications Web des applications mobiles.
Signalons enfin que les Single Page Applications prennent tout leur sens dans le cadre d’architectures microservices, où les API sont conçues ex-ante, selon une logique métier indépendante des frontaux clients. Dans ce cadre, une SPA est susceptible de faire appel à différentes API et possède son cycle de vie propre. En toute rigueur, les applications traditionnelles ne sont pas exclues des architectures microservices, pouvant elles-mêmes faire appel à différentes API, mais ce cas est plus rare. Quoi qu’il en soit, cette vision reste assez théorique, peu d’acteurs ayant à ce jour emmené leur système d’information à ce niveau de maturité.
Coût des Single Page Applications
Le surcoût de ces dernières est réel et s’explique.
Les vraies architectures microservices restant rares, c’est bien souvent à l’occasion du développement de la SPA que l’on met en place l’API correspondante. Même si cette dernière est conçue dans les règles de l’art, autour des objets métier et non des besoins de la SPA, il reste vrai que l’API n’aurait pas existé en l’absence de la SPA. Pour cette raison, nous pouvons dire que mettre en place une SPA revient à mettre en place une SPA et une API, soit deux “efforts” contre un seul dans le cas d’une MPA. Le coût d’une SPA est donc, en ordre de grandeur, le double de celui d’une MPA.
Il y a en premier lieu le bootstrap de l’application et la mise en place du pipeline CI/CD de la SPA. Ce coût fixe constitue le “ticket d’entrée” de la mise en place d’une SPA.
Il y a ensuite la mise en place de la persistance de l’état applicatif (ex : Redux) et du lien avec les vues (ex : React) : l’utilisateur, au travers des vues, va initier des actions, qui pourront être à l’origine d’échanges de données avec les API et qui, dans tous les cas, vont modifier l’état applicatif. La mise à jour de ce dernier entraînera en retour la mise à jour des vues. Toute cette mécanique qui, dans le monde Redux, repose sur des Action Builders, des Thunks et/ou des Epics, des Reducers et des Selectors, constitue la majeure partie du travail. Sans oublier les tests unitaires, d’intégration et tests end-to-end, tous préférentiellement écrits dans le cadre d’une approche TDD. Ainsi, de mon expérience, la mise en place des vues ne constitue pas plus de 10% de la charge totale alors que c’est la seule chose que le commanditaire voit. Ce hiatus explique sans doute des remarques du type : “il suffit de rajouter un bouton” !
Il faut également mettre en place un grand nombre d’échanges réseau (requêtes XHR ou notifications) parce que le back-end reste garant des règles de gestion métier. Il ne serait pas absurde de faire appel au serveur pour, à la fin, ne procéder qu’à une simple addition, tout simplement parce que le front-end n’a pas à savoir que l’opération consiste en une simple addition. Cette complexité, elle non plus, n’est pas perçue par le commanditaire.
Néanmoins, on souhaitera donner à l’utilisateur des feedbacks rapides, réguliers et en amont du processus : il est hors de question de laisser l’utilisateur saisir des données pendant 10 minutes pour lui annoncer seulement à la fin que la première donnée saisie est erronée, surtout si elle conditionne les autres. Des contrôles à la saisie doivent être implémentés côté front en plus des mêmes contrôles effectués côté back, parce qu’il reste de la responsabilité de l’API de vérifier les données d’entrée.
Enfin, de nombreuses choses insignifiantes ou un peu évidentes se révèlent avoir un coût : affichage des états intermédiaires (“en cours de chargement…”), gestion des cas d’erreurs réseau (information de l’utilisateur, retry) ou bien encore la gestion des points d’entrée dans l’application (mise en favoris, partage par lien).
Tout cela nécessite une expertise pointue sur des architectures et technologies nombreuses mais ayant toutes vues le jour il y a moins de 10 ans. Les compétences sont donc rares sur le marché et se paient à bon prix. Charge de développement accrue et taux journaliers élevés se multiplient et expliquent le coût élevé des SPA.
Une question de valeur ajoutée
L’expérience montre que cette nouvelle donne n’est pas encore prise en compte par la majorité des entreprises, qui, loin de répercuter la hausse sur leurs budgets informatiques, demandent ces nouvelles réalisations alors même que leurs budgets sont inscrits à la baisse. Les fournisseurs de services, lorsqu’ils travaillent encore au forfait, semblent pour certains découvrir cette réalité et s’engagent sur des chiffrages dramatiquement sous-évalués. Mais les déconvenues existent aussi dans des organisations ayant adopté des pratiques agiles, pourtant a priori plus “mûres” sur ces sujets. “Ca finit par coûter cher”, disent-elles.
Vraiment ? Les SPA coûtent-elles cher ? Il faut surtout prendre acte du fait que le service rendu à l’utilisateur est bien plus élevé que celui rendu par une application classique. On parle d’ailleurs de manière équivalente de Rich Internet Applications (RIA).
La question serait-donc plutôt de savoir si le contexte métier requiert ou peut supporter le coût additionnel d’une expérience utilisateur augmentée. Autrement dit, quelle est la valeur ajoutée d’une SPA pour le métier concerné ? C’est un fervent amateur des SPA qui le demande !
La réponse n’est pas nécessairement en faveur de la mise en place d’une Single Page Application : à titre d’exemple, Amazon a considéré qu’une MPA était la meilleure solution pour son site marchand.
Bonjour Mathieu, tout d’abord merci pour ton article !
J’ai une petite question cependant, je ne vois pas ce que l’architecture micro service vient faire dans cet article.
Tu dis “Signalons enfin que les Single Page Applications prennent tout leur sens dans le cadre d’architectures microservices”, et je dois te dire que je ne suis pas du tout d’accord avec toi sur ce point.
D’une part ton front n’a pas à connaître de près ou de loin ton architecture back (ou du moins le moins possible). D’autre part que ta SPA tape un ou plusieurs serveurs derrière ne change absolument rien pour cette dernière. Tu peux faire un monolithe ex-ante que consomme ta SPA, comme du miroservices. Par contre en effet si tu fais du microservices alors tu exploses d’autant plus les coûts car là où tu n’avais qu’un serveur tu en a une dizaine voir plus !
Merci
Arthur