Les développeurs d’applications, comme leur nom l’indique, aiment développer des applications – ils se soucient finalement très peu du frontend par rapport au backend et veulent juste offrir de la valeur aux utilisateurs. Étant moi-même développeur d’applications, et tout comme les autres développeurs d’applications, l’une des choses qui motivent constamment ma prise de décision lors de la sélection d’outils et de frameworks est le fait que je suis également assez paresseux.
Mon objectif principal est de pouvoir expédier des applications avec le moins d’effort possible, et ma bête noire est des tâches stupides et répétitives et mécaniques qui me font mourir un peu à l’intérieur à chaque fois que je dois les exécuter. Par exemple, je n’aime pas me souvenir d’aligner des choses qui ne s’alignent pas automatiquement, comme exemple courant d’une tâche répétitive complètement superflue. Je suppose que ma marque de fabrique est que lorsque je rencontre des défis, je cherche toujours des moyens d’automatiser une solution. (Comme l’application que j’ai créée dans les années 90 pour envoyer un SMS romantique à ma petite amie une fois par jour – pour surmonter mes lacunes romantiques).
J’ai construit des outils et des frameworks pour augmenter la productivité des développeurs pendant la majeure partie de ma carrière professionnelle. Tout a commencé en 2006 lorsque j’ai identifié un besoin de modernisation des applications créées à l’aide d’un générateur de code bas vers C#.NET. J’ai décidé non seulement de créer une solution de migration entièrement automatisée, mais, plus important encore, de créer une bibliothèque de classes C # qui permettrait une vitesse de développement équivalente à celle qui était auparavant rendue possible en utilisant l’outil low-code.
C’était une barre très haute, car les développeurs qui ont l’habitude de travailler avec du code bas sont aussi souvent du genre à ne pas aimer les détails ou les bits et octets des composants internes. Un développeur heureux d’utiliser des outils low-code ne cherche essentiellement qu’à écrire du code permettant d’accomplir une tâche spécifique. Pouvoir reproduire cela dans un cadre de codage devait fournir une expérience aussi transparente et simple que jusqu’à présent, mais avec du code.
Des centaines d’organisations ont utilisé la solution de migration de Firefly, des Fortune 500 et des gouvernements aux petites sociétés de logiciels. La bibliothèque C# fournie est toujours utilisée aujourd’hui, permettant le développement d’applications hautement productives à « faible niveau de code », combinées à la flexibilité du code.
La possibilité de livrer efficacement des applications complètes avec une simple bibliothèque, pour moi, ressemblait à quelque chose qui devait être portable et répliqué sur le Web moderne. Les roues ont commencé à tourner.
Ce qui nous a amené ici
Comme beaucoup d’autres développeurs Web, lorsque Node.js est sorti, j’étais enthousiasmé par la promesse du backend au frontend qui l’accompagnait, qu’enfin, nous n’avons pas besoin d’apprendre deux langages pour créer une application complète. Juste le simple changement mental entre les langues – pour moi, c’était C # sur le backend, puis Javascript sur le frontend, et cela s’accompagnait toujours de frictions et de changements de contexte qui pouvaient même être considérés comme débilitants pour mon workflow de développement.
Même avec la possibilité présentée par Node.js d’activer Javascript aux deux extrémités, peu de développeurs ont choisi de le faire. Toutes les meilleures pratiques et ressources d’apprentissage ont continué à recommander l’utilisation de deux approches distinctes pour le backend et le front et une séparation complète des outils, des bibliothèques et des frameworks avec très peu de partage de code et de modèles pour le frontend et le backend.
Ce modus operandi d’avoir deux langages distincts, chacun avec sa propre syntaxe et logique, crée le besoin de beaucoup de passe-partout répétitifs, tels que le code pour extraire les données de la base de données (pour chaque entité d’application), le code pour exposer l’entité CRUD opérations en tant qu’API, avec quatre, cinq ou même six routes différentes par entité, des méthodes pour ces routes, et tout cela serait à nouveau dupliqué et réutilisé des centaines de fois, et chaque fois encore plus compliqué. Vous avez eu l’idée.
Et c’est juste sur le backend.
Maintenant, sur le frontend, vous avez un code inversé pour cela ; vous avez du code qui prend ces réponses JSON et reconstruit des objets à partir de celles-ci pour que vous puissiez les utiliser sur le frontend. J’essaie simplement d’obtenir des données de la base de données pour les utilisateurs, mais, en attendant, vous avez besoin de code pour lire la base de données, sérialiser le JSON et l’envoyer sur une route, seulement pour avoir à désérialiser et à l’interroger sur le frontend, juste pour le mettre devant l’utilisateur.
Tout cela est un code mécanique qui ne fait pratiquement rien. Où finalement, tout cela est répétable.
Attendez, il y a plus. Chaque route d’API doit pouvoir récupérer des données, fournir une pagination côté serveur, un tri et un filtrage, supprimer, insérer et mettre à jour ; toutes ces actions très génériques sont répétées encore et encore par tous les développeurs qui créent en permanence des applications complètes dans des millions de lignes de code.
Parlons maintenant des problèmes qui se chevauchent du frontend au backend et qui sont dupliqués. Jusqu’à il y a quelques années, le frontend et le backend partageaient, au mieux, des types, mais il y a tellement plus dans les types que des chaînes ou des entiers.
Questions courantes telles que :
- Comment les sérialisez-vous à partir de JSON puis vers JSON ?
- Comment les validez-vous ?
Aujourd’hui, les validations sur le frontend et le backend sont des opérations complètement séparées. Ce qui pose la question : POURQUOI ? Pourquoi devrais-je me rappeler (en tant que développeur paresseux, remarquez) de devoir effectuer deux validations distinctes sur le frontend et le backend ?
Code passe-partout en double
Il y a aussi un aspect culturel avec cette dichotomie entre le code frontend et backend, où il doit y avoir une communication et un alignement irréprochables entre les développeurs qui est presque un exploit impossible. En fin de compte, tous ces endroits sont des lieux de friction où les choses peuvent mal tourner, avec deux développeurs complètement différents qui maintiennent le code.
Entrez Rémul
Vous souvenez-vous quand j’ai dit que lorsque je rencontrais un défi, mon premier plan d’action était d’essayer de l’automatiser ? Je ne pouvais pas comprendre comment, en 2018, il n’est toujours pas viable de pouvoir exécuter le même code sur le frontend et le backend. J’ai commencé à jouer avec cette idée pour voir si je pouvais vraiment rendre cela possible et améliorer ma productivité (et, espérons-le, pour d’autres développeurs aussi) – des validations à la saisie, en passant par l’authentification et l’autorisation, tout le code typique qui est constamment dupliqué.
Histoire de Remul
Remult a commencé comme un projet parallèle sans nom et avec un objectif complètement différent (quoique noble). Ma femme a fait du bénévolat dans une banque alimentaire et, par conséquent, j’ai moi aussi été bénévole pour participer à la distribution de colis alimentaires aux nécessiteux. Un jour, alors que je conduisais pour distribuer les colis, tenant un papier avec une liste d’adresses, je me suis retrouvé à me perdre dans des endroits où vous ne voulez pas vous perdre, et j’ai su que je devais créer une application pour aider les bénévoles à naviguer efficacement. Je savais que je pouvais résoudre beaucoup de frictions dans le processus de livraison de colis alimentaires aux nécessiteux via le code – ce que je fais le mieux, et je voulais me concentrer sur la création de l’application réelle et de ses capacités, et non sur les pièces qui tiennent ensemble.
J’ai donc créé une application pour l’inventaire et la distribution de notre banque alimentaire locale à Even Yehuda, une application qu’ils pourraient utiliser pour générer des listes de distribution pour les coursiers bénévoles et pour que les coursiers puissent naviguer et rendre compte de la livraison. J’ai écrit l’application et, en même temps, le framework, le framework même que je voulais avoir lors de la création d’applications Web. Celui qui se concentrerait sur le flux de données de la base de données backend vers le framework frontal (le framework de votre choix – qu’il soit Angular, React ou Vue – cela ne devrait pas avoir d’importance).
Au lieu d’avoir à passer par l’ensemble du processus décrit ci-dessus de sérialisation des objets pour chaque appel HTTP sur le frontend, puis d’inverser l’ensemble du processus dans JSON du backend au frontend, ce framework a permis d’interroger sur le frontend, en utilisant objets, puis automatisé l’ensemble du processus du frontend au backend et vice-versa. J’ai enfin eu le cadre dont je rêvais qui élimine le besoin d’écrire tout ce code passe-partout, répétitif, encore et encore.
Avec sa croissance et son utilisation, un collègue et moi avons travaillé sur le framework, investi dans sa capacité à évoluer et sa stabilité, amélioré son API qui a subi plusieurs itérations et ajouté de nombreuses fonctionnalités. L’application construite sur ce cadre a été rapidement adoptée par d’autres banques alimentaires en Israël, qui ont souvent rencontré des défis similaires avec la livraison de colis. Notre application, après sa première année, a réussi à aider à distribuer 17 000 colis de banques alimentaires à travers Israël. Nous étions assez fiers de cette réalisation – nous avons commencé à penser que notre cadre pouvait résister à l’épreuve de l’échelle, mais nous n’avions aucune idée de ce qui allait suivre.
Ce que COVID nous a appris sur l’échelle et la sécurité
Puis COVID a frappé – et les blocages ont coupé les personnes dans le besoin du monde entier. Soudain, le besoin de distribuer de la nourriture aux personnes âgées et handicapées a monté en flèche. La demande est passée de 17 000 colis par an à 17 000 colis par jour. L’application a ensuite été fournie gratuitement aux municipalités, aux ONG et même au front intérieur de Tsahal pour permettre un meilleur inventaire, attribution et distribution des colis à travers Israël.
Une fois l’application adoptée par Tsahal, elle a également subi une batterie de tests de sécurité – des tests de cyber et de pénétration, qui ont considérablement amélioré sa sécurité. Le cadre backend-to-frontend et l’application sur laquelle s’appuie, qui était censée n’être qu’une expérience, ont résisté à l’échelle d’un demi-million de distributions de colis rien qu’en 2020 et depuis lors, ils ont maintenu un nombre similaire et ne font que croître. Pendant le COVID, il a été adopté par plusieurs pays du monde – de l’Australie à l’UE, en passant par les États-Unis et l’Afrique du Sud – pour répondre à des besoins similaires pendant la pandémie.
C’est l’épine dorsale sur laquelle Remult a été construit et testé au combat, fonctionnant sur un serveur Heroku à 16 $ par mois.
Une fois la pandémie derrière nous, mon co-créateur et moi avons réalisé que nous avions beaucoup appris. Nous avons compris que le cadre était robuste et pouvait évoluer, était…