Note : Ce contenu a été créé avant que Fabernovel ne fasse partie du groupe EY, le 5 juillet 2022.

‍

Au travers de la grande variété des produits mobiles que nous avons eu la chance de concevoir, nous avons pu constater que la qualité de ceux-ci découlait d’une symbiose entre le front end, l’interface mobile, et le back end, la partie serveur du produit.

C’est pourquoi nous avons aujourd’hui choisi de vous révéler comment nous composons un back end orienté mobile chez Fabernovel.

De quoi est composé un back end ?

Comme pour les autres sujets relatifs au développement, le back end est un domaine où donner une description exhaustive de son fonctionnement, requerrait quelques milliers d’articles. Nous avons ici choisi de nous concentrer sur les principaux ingrédients, laissant les autres pour de futures publications.

Un serveur web

Le serveur web est la partie du back end responsable de la communication réseaux avec les clients. Le cas d’école n’est pas très palpitant, le serveur ne fait en effet qu’établir une connexion avec un unique client modèle. Il s’assure que toutes les données envoyées par le client soient correctement transmises aux autres parties du back-end, et la réponse soit bien reçue par le client.

Cependant la réalité est nettement plus complexe. Tout d’abord, un client n’attend pas que le précédent ait fini sa demande avant de s’adresser à votre serveur. Ensuite, car votre produit est génial, il n’y aura pas un ou deux clients de temps en temps, mais plutôt des centaines chaque minute. Enfin, car vos clients ne peuvent plus se passer de vous, ils essaieront même de se connecter à votre back end lors de leurs trajets quotidiens. Or une connexion dans les transports signifie une mauvaise connectivité, ce qui engendrera une connexion bien plus longue que la normale, ce qui fera passer son temps à votre serveur à attendre ce que l’on appelle les clients lents.

Pour surmonter ces trois problèmes, les serveurs web possèdent différentes stratégies comme le cache ou les connexions parallèles. Cependant chacune de celles-ci est une concession entre le service offert et les ressources consommées. Vous devrez donc chosir le serveur qui effectue les concessions qui correspondent à votre produit.

Notre choix : Phusion Passenger

Nous avons choisi Passenger, comme une majorité de la communauté Rails (et notamment l’équipe à l’origine de Rails). Il est en effet capable de gérer des connexions en parallèle, est économe en mémoire et profondément intégré avec NGINX, ce qui lui permet entre autres de servir très efficacement les ressources statiques. C’est l’ensemble de ces caractéristiques qui a fait que notre choix s’est porté Passenger, au regard du fait que les back ends sont souvent hébergés sur des instances avec un hardware limité.

Un framework d’application web

Récupérant la requête depuis le serveur web, cette partie du back end analyse les différents attributs de celle-ci pour comprendre la demande du client et lui formuler une réponse en retour. Le rôle de cette couche est très différent d’un projet à l’autre, c’est donc logiquement celle où le travail du développeur est le plus important. C’est pourquoi ici on n’utilisera pas un produit sur étagère sur lequel on modifiera quelques réglages, mais on choisit un framework qui permettra de structurer et d’accélérer le développement.

Un framework, même s’il ne peut être vu que comme un simple cadre, possède un très fort impact sur le projet. Notamment du fait qu’il s’agit de la partie où la plupart des calculs sont effectués, il joue un rôle majeur dans les performances globales du back end. De plus les frameworks, en fonction de leur popularité, n’auront pas tous la même quantité de ressources disponibles (documentations ou librairies). Enfin certains, de par leur fonctionnement interne, empêcheront l’application d’utiliser certaines fonctions web (comme le push-pull).

Le choix du framework est très certainement le choix le plus critique parmi les différentes parties. Passer d’un framework à un autre peut en effet demander une réécriture quasi complète de votre projet. Prenez donc votre temps, et pesez bien le pour et le contre de chacun des frameworks.

Notre choix : Ruby on Rails

De nombreux frameworks sont activement utilisés et maintenus. Il n’en existe pas un qui soit le meilleur dans tous les domaines, mais il y en a surement un qui correspond plus à vos besoins. En ce qui nous concerne, c’est Ruby on Rails qui a répondu le mieux à nos attentes.

Les critères qui ont contribué à notre décision sont :

• La maturité : bien que nous aimions jouer avec les dernières technologies, nous savons qu’un framework a besoin de temps pour prouver sa fiabilité. Créé en 2004, Ruby on Rails a depuis grandi chaque année pour devenir aujourd’hui un des frameworks les plus utilisés. S’il est assez fiable pour Github ou Basecamp, il devrait l’être pour vous.
• Open source : utiliser un framework open source permet notamment de parcourir le code source quand on cherche l’explication pour un comportement donné, ou quand on souhaite y ajouter une fonctionnalité maison.
• Une mise en place éclair : développer un back end à destination du mobile est un exercice dans lequel une qualité se révèle être cruciale, la réactivité. Nos clients adorent notre capacité à lancer ou mettre à jour une API en quelques jours. Dans cette perspective Ruby on Rails, par l’utilisation de conventions au lieu de configurations (CoC), amène une rapidité de développement supérieure à celle de ses concurrents.
• La force de l’écosystème : la plupart des problématique rencontrées aujourd’hui par les développeurs l’ont certainement été par d’autres auparavant. Ainsi ce n’est pas seulement les fonctionnalités d’un framework qui définissent sa qualité, mais aussi la richesse des librairies conçues par sa communauté au fil du temps. Dans de ce domaine Ruby on Rails profite du gestionnaire de librairies de Ruby, RugyGems.
• L’attrait pour les développeurs : nous, ingénieurs Applidium, sommes des êtres humains sensibles et sommes bien conscients qu’un développeur qui aime son travail y excellera d’avantage. Ruby propose donc une syntaxe, qui associée aux conventions de Rails, fait de nous les plus heureux des développeurs ;-)

Une base de données

Contrairement aux deux précédentes couches, celle-ci est plutôt bien connue du public non technophile. En effet, le grand public sait en général que derrière un site web se cache une base de données. Cette couche, comme son nom l’indique, est responsable du stockage de toutes les données permanentes.

Historiquement cette donnée a été stockée de sorte qu’elle puisse requêter d’une manière très efficace, avec le bien nommé Search Query Language (SQL). Cependant pour être capable d’utiliser ces requêtes, les bases de données doivent conserver les données ordonnées de manière relationnelle, ce qui a un coût en termes de performance, et impose d’héberger la base de données sur une seule et même machine. Avec l’apparition du gigantisme des données (big data), les développeurs ont commencé à travailler avec des bases NoSQL, concédant des possibilités de requête contre de meilleures performances et la possibilité de monter en capacité en hébergeant leurs bases sur différentes machines.

La partie base de données, en dehors du choix entre SQL et NoSQL, est celle où les normes font que les différentes solutions sur le marché sont plutôt similaires. Les différences se jouent dans les détails, et vous pouvez choisir une solution sans risquer de mettre en péril tout votre projet.

Notre choix : PostgreSQL

Du fait de notre choix (Rails), nous avons restreint notre panel de sélection aux 3 bases de données supportées nativement par ce framework : SQLite, MySQL, PostgreSQL. Si SQLite est la base de données par défaut de Rails, elle n’est cependant pas adaptée aux applications web où de multiples instances partagent la même base. Choisir ensuite entre MySQL et PostgreSQL n’a pas été simple, du fait que les deux ont des performances et caractéristiques très similaires. C’est en prenant en compte l’avis des communautés supportant ces projets, que l’indépendance et la bonne réputation de celle de PostgreSQL a su faire pencher la balance en sa faveur.

Un hébergeur

Les 3 précédentes parties ne concernaient que l’aspect logiciel de notre back end, mais au final chacun d’eux nécessitent du matériel sur lequel fonctionner. S’il est toujours possible d’héberger son serveur dans sa cave, il est aujourd’hui préférable d’externaliser ce service.

Tout d’abord il y a le problème des défaillances matérielles. Une disponibilité de 99.9% est aujourd’hui la norme, et atteindre cette performance requiert des investissements matériel lourds (comme la redondance de toutes les parties critiques du système). Ensuite, l’externalisation vous permet de tirer avantage du cloud.

Vous donnez simplement à votre fournisseur cloud une image de votre application, et vous décidez ensuite combien d’instances de cette image vous souhaitez activer. Plus besoin de paramétrer les serveurs physiques les uns après les autres, ici vous jouez simplement avec un curseur pour lancer de nouvelles instances. Ce type de fonctionnement vous permet de payer exclusivement pour ce dont vous avez besoin, en fonction de l’évolution de la charge de votre service.

Notre choix : Heroku

Avec la démocratisation du cloud, le grand public a tendance à penser que toute la complexité de la partie hébergement est maintenant gérée par les fournisseurs de cloud. S’il est vrai qu’ils s’occupent de toutes les problématiques matérielles, les développeurs ont encore à leur charge la partie logicielle de l’hébergement.

C’est pourquoi en complément du service de cloud classique, plusieurs entreprises ont mis au point des plateformes qui s’occupent aussi de la partie logicielle. Ces plateformes, un peu plus onéreuses que les fournisseurs de cloud traditionnels, épargnent aux développeurs un temps considérable de maintenance logicielle. Souvent perçu comme une dépense superflue, ce surcoût se révèle au final être une économie en comparaison aux nombreuses heures qu’un développeur aurait passé à maintenir l’application web.

De toutes les plateformes que nous avons pu découvrir et expérimenter, il n’y a pas de doutes qu’Heroku est notre choix numéro 1 :

• Heroku fonctionnant sur le cloud Amazon, référence du secteur, il dispose d’une des plus hautes disponibilités du marché.
• Année après année Heroku a successivement ajouté le support de technologies toujours plus nombreuses, si bien qu’aujourd’hui il supporte toutes celles que nous utilisons, et les probabilités sont bonnes pour que les prochaines que nous utiliserons le soient aussi
• Pour des projets au trafic modéré, Heroku offre un excellent rapport temps de développeur économisé sur coût supplémentaire par rapport à un cloud classique.
• La popularité d’Heroku est telle qu’un écosystème d’add-ons s’est créé autour de cette plateforme. Ceux-ci y sont aujourd’hui très bien intégrés, et permettent de bénéficier de nombreux et précieux services, qui peuvent simplement être ajoutés en une simple commande.
• Une bonne partie des back-ends que nous avons réalisés servent du contenu multimédia. Que ce soit en termes de performance ou de coût, ce n’est pas le genre de contenu que vous souhaitez servir depuis votre web application. Il est de loin préférable d’utiliser un site d’hébergement de fichiers. Heroku fonctionnant dans le cloud Amazon, vous pouvez économiser tous les coûts de transfert entre votre serveur, et le service de stockage de fichiers de référence, Amazon S3.

Conclusion

Fort de notre sélection attentive de technologies, combinée à l’efficacité de notre stack back-end, nous sommes aujourd’hui en mesure d’offrir à nos clients une réalisation rapide et fiable de back end orienté mobile. Nous n’avons certes pas choisi les solutions les plus économiques, mais celles qui nous offraient une portabilité et une adaptabilité maximum.

De plus, nous restons à l’affut de nouveaux composants qui pourraient à l’avenir faire évoluer notre stack. Nous gardons en effet à l’esprit qu’une application réussie n’est rien d’autre qu’un flux de données en temps réel savamment présenté.