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.
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.
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.
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é.
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.
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 :
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.
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.
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.
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 :
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é.
Les innovations de l’écosystème entrepreneurial français à destination des nos aînés.
Lire la suite
Découvrez comment la blockchain peut apporter de multiples avantages dans le secteur de la supply chain.
Lire la suite
Le développement de la Blockchain a rebattu les cartes dans le domaine des contenus numériques. Les auteurs l'envisagent désormais comme une opportunité pour retrouver la propriété et l’usufruit de leur travail, sans passer par un annonceur. Mais cette nouvelle technologie et celles qui — plus largement — participent à l’émergence du Web3, peuvent-elles réellement recentrer la valeur sur les contenus, plutôt que sur les plateformes ? Pour le comprendre, nos experts décryptent les dynamiques qui agitent et font évoluer ce nouveau modèle.
Lire la suiteEY refers to the global organization, and may refer to one or more, of the member firms of Ernst & Young Global Limited, each of which is a separate legal entity. Ernst & Young Global Limited, a UK company limited by guarantee, does not provide services to clients.
