Passer de frontend à backend - le réseau

Mon quotidien fait que je rencontre énormément de développeur Backend et Frontend, à différent niveaux de compétence pour qui le sujet back/front est toujours un débat. Pourtant, je reste persuadé que l'on peut faire les deux, à partir du moment où on en ressent le besoin.

Dans mon cas j'ai commencé sur du dev système avec du C, C++ et à un moment de ma vie, j'ai eu à coder des interfaces. Au départ, c'était des IHM (interface homme-machine) en C++, puis en passant sur du Web, j'ai commencé à coder des vues HTML.

Aujourd'hui, je vais tenter de mettre le doigt sur les compétences à maîtriser pour pouvoir coder du backend lorsque l'on est plutôt orienté frontend. Cet article fait partie d'une série de plusieurs articles que je posterai dans les jours qui viennent.

Qu'est-ce qui fait que je n'ai pas de préférence particulière ?

Le fait d'avoir une réelle compréhension de ce qu'il se passe des deux côtés fait qu'il n'y a rien de mystique à mes yeux. Et quand on n'a aucune barrière mentale, tout est possible. C'est pourquoi, dans cette série d'articles je vais lister les éléments à comprendre et à maîtriser afin de vous aider à passer du front au back.

Prêt ? 😊

Appréhender le développement backend

Tant que le mot "backend" ne déclenche pas de frissons chez vous et un brun de dégoût, c'est qu'il y a de l'espoir ! Le code backend a beaucoup de charme et vous vous porterez bien mieux en comprenant un peu ce qu'il se passe de l'autre côté du réseau.

Comprendre le backend vous permettra de travailler sur vos propres API (interface de programmation), c'est à dire la brique que vous allez appeler pour effectuer des opérations :

• insertion en base
• appels de devices
• interaction avec l'extérieur (paiement, services, etc...)

Vous serez en mesure de faire un produit complet de A à Z, bien que, je préfère le dire, la partie backend se décompose en plusieurs compétences :

• le développeur backend : qui se concentre sur les services API
• le sys dba : qui maîtrise les bases de données
• le sys admin : qui maîtrise le déploiement

Le réseau

La communication front/back se fait toujours par le biais du réseau. Cela implique qu'en fonction du protocole utilisé côté backend, il vous faudra comprendre comment cela fonctionne et ce que cela implique.

Généralement, sur des technologies Web, on est sur du TCP pour des échanges client-serveur standard et parfois de l'UDP pour l'image, la voix ou des échanges intenses comme les jeux en ligne.

Pour faire simple, le protocole TCP implique une stricte vérification de chaque paquet reçu pour être sûr que tout correspond au message initial. En cas de paquet perdu, le protocole demande à réémettre le paquet. Il y a tellement de vérification pour que rien ne passe à la trappe que l'on dit que ce protocole est orienté qualité/fiabilité, mais cela implique aussi quelques lenteurs. A contrario, l'UDP est un protocole basé sur l'efficacité. On ne fait pas de vérification de paquet, juste des échanges en faisant "confiance" au pair connecté. Et ce "non-contrôle" fait de lui le protocole le plus rapide des deux.

Et ce qui va sortir et entrer de votre interface réseau dans vos applications (votre carte wifi ou votre carte ethernet) sera en TCP ou UDP. Ce qui signifie que c'est au dessus de cette brique, que viendra se poser les autres protocoles de plus haut niveau.

Lorsque l'on est développeur Web, on travaille essentiellement avec de l' HTTP pour nos API. Nous distinguons alors 2 choses : la requête (ce que le client demande) - la réponse (ce que le serveur retourne).

Commençons par les réponses HTTP

Ce qu'il faut garder en tête lorsque l'on communique en HTTP avec un serveur c'est que le code de statut ou encore status code nous explique ce qu'il s'est passé sur le serveur.

Par exemple : Status 200 - tout est ok

Dans les grandes lignes :

• Status 2XX : ok
• Status 3XX : redirection, ou page non modifiée (généralement interprété directement par le navigateur)
• Status 4XX : erreur de la part du client (autorisation non suffisantes, page introuvable, etc...)
• Status 5XX : erreur de la part du serveur (un service a mal répondu ou un bug dans le code)

Associé à ce statut, il y a parfois un message mais notez que souvent le message est absent, surtout dans les cas d'erreur, car le statut est déjà suffisant pour donner l'information.

Les requêtes HTTP

Pour les requêtes, on va dire que cela dépend de l'architecture que vous utilisez. Le plus souvent, on passe par du REST API , c'est à dire faire des requêtes dont le header "method" décrira le type d'action que l'on souhaite faire :

• GET : généralement utilisé pour les lectures
• POST : généralement utilisé pour les écritures
• PATCH : généralement utilisé pour mettre à jour quelques champs d'un modèle
• PUT : généralement utilisé pour remplacer totalement un modèle
• DELETE : généralement utilisé pour supprimer un modèle

Et grâce à ces méthodes on va créer les routes pour effectuer les opérations de type CRUD (Create, Read, Update, Delete). Notre front n'aura plus qu'à consommer ce service en appelant les routes avec les bons paramètres et le tour est joué. Notre serveur répondra en effectuant les opérations nécessaires.

Il existe aussi d'autres architectures de requêtes comme GraphQL qui n'utilise que les requêtes de type POST et permet de faire des opérations de type :

• Query : pour lire des informations depuis le serveur
• Mutation : pour écrire des informations depuis le serveur (que ce soit Create, Update ou Delete)

Le GraphQL utilise une syntaxe particulière qu'il vous faudra apprendre et comprendre avant de pouvoir évoluer confortablement avec cette architecture.

La différence majeure entre ces deux architectures : REST et GraphQL, c'est que GraphQL se concentre sur l'efficacité des trames réseaux car il permet de récupérer des champs spécifiques en lecture et écriture (donc contrôler la taille du trafic réseau, alors que REST renverra systématiquement tous les champs d'une réponse (à moins de coder un système de data picker en paramètre...).

Point d'attention sur cette partie réseau

Lorsque vous choisirez votre architecture HTTP, je vous conseille de bien respecter les conventions.

Sur du REST, je vous recommande d'être rigoureux sur la création de vos routes. Il y a des patterns à bien respecter, par exemple : method: DELETE route: /post est largement suffisant pour décrire une action de suppression d'un post, évitez les routes: /post/supression... 😅

Le choix du framework

Peu importe le langage de programmation que vous utilisez, lorsque vous devez coder une API, vous allez au plus simple en sélectionnant un Framework qui va accélérer votre développement et cadrer les choses. Avec Node.js, ils sont nombreux, entre Express, Hapi, Koa, Nest, etc. Les principes restent les mêmes, effectuer des échanges réseaux client-serveur et gérer les requêtes en envoyant des réponses.

Par ailleurs, il est tout à fait possible d'opter pour un framework dédié au serverless. C'est à dire que le framework va organiser le code de manière à être déployé sur des services managés par des providers tels qu'Amazon ou Google. C'est un choix envisageable et plein de sens, totalement dans l'air du temps, efficace puisque vous vous concentrez sur le code, mais aussi plus couteux.

De même Next.js est un peu, à sa façon, un très bon compromis. En effet, ce que vous produisez comme code pourra être déployé via Vercel un service managé dédié à Next.js (solution que j'ai testé sur une mission, et qui s'avère incroyablement efficace), tout en vous donnant la possibilité de déployer vous même à moindre coût si vous le souhaitez (solution pour laquelle j'ai opté pour ce blog 😃).

Meteor.js est un peu un ovni à sa manière avec son protocole DDP qui va mixer plusieurs technologies entre l'HTTP, le RPC, les sockets... N'hésitez pas à consulter les quelques articles que je poste sur le sujet, car je suis moi même un utilisateur de Meteor.

Pour aller plus loin

Sachez qu'il existe un projet qui se démocratise de plus en plus ces derniers temps : le WebRTC pour de la communication Web. Il est surtout utilisé pour transporter la voix ou l'image, parfois pour chatter mais c'est rare. Ce protocole peut fonctionner autant sur du TCP ou sur de l'UDP, bien que l'UDP soit privilégié.

Dans le prochain article on parlera des bases de données, toujours dans l'optique de passer de développeur frontend au développeur backend. 😉