De nombreux clients font appel à One more thing Studio pour réaliser leur projet. Ce projet, c’est rendre un service spécifique à des utilisateurs, grâce à une application mobile. Le challenge est donc de développer une application.
Évidemment, tout le monde sait ce qu’est une application : à quoi ça ressemble (un enchaînement d’écrans dans un smartphone) et comment on s’en sert pour afficher un contenu souhaité (en touchant des endroits spécifiques dans l’interface). Ça c’est la partie visible de l’iceberg qu’on appelle front-end, assez facile à comprendre pour ceux qui ne partagent pas la « culture geek ».
Cependant, une application possède aussi une partie invisible, plus technique, qui est responsable de son fonctionnement : le back-end. C’est la partie cachée de l’iceberg, absolument nécessaire pour que les interactions entre utilisateurs et interfaces soient réussies.
Au niveau technique, de quoi une application a-t-elle besoin pour exister ? Essayons de répondre à cette question (et rendons le monde meilleur !)
Pour que l’explication soit plus sympa, je vais utiliser l’application Melckone afin d’illustrer mes propos : le service que propose ce produit, c’est une promenade en forêt en toute sérénité car l’application permet d’éviter les zones de chasse et les dangers de la nature. Nous allons y revenir.
Globalement donc, une application mobile doit savoir faire deux actions : afficher des informations et en recueillir.
Pour faire cela, elle doit s’appuyer sur un serveur (l’autre nom du back-end) : c’est une machine dotée d’un logiciel qui alimente l’application en données ou qui sauvegarde les données qui auraient besoin d’être préservées (comme par exemple les données du profil d’un utilisateur).
Ces données sont rangées de manière organisée dans une base de données, elles sont inter-liées et propres à chaque application. Ce système de stockage très structuré permet de manipuler les données assez simplement car il répond à des requêtes.
Ces requettes sont formulées par une API (Application Programming Interface) : un système qui joue le rôle de facilitateur d’échanges entre l’application et la base de données. En fait, l’API est un traducteur nécessaire entre l’application et la base de données puisqu’elles ne parlent pas la même langue. Souvent, une application se sert d’API qui existent déjà (par exemple l’API de Google Maps qui permet d’afficher une carte avec des coordonnées GPS) mais il est également possible de créer des API, capables de répondre à un besoin spécifique (qu’on appelle API interne).
Les requêtes de l’API dites “REST” sont assez simples : sous la forme d’un verbe non ambigu (GET, POST, PUT, DELETE…), elles manipulent la base de données pour réaliser la tâche demandée et satisfaire l’utilisateur.
Par exemple, quand l’utilisateur est sur la carte de l’application Melckone (côté front-end), il doit pouvoir voir les potentiels dangers qui sont autour de lui : à ce moment-là, l’application demande à l’API REST de retourner les dangers via une requête “GET”. Cette requête est traduite par l’API REST en une requête compréhensible (autre langage) par la base de donnée qui lui retourne alors les dangers. Ces données sont enfin formatées par l’API REST et retournées au front-end pour affichage. Puisqu’il s’agit d’une carte avec géolocalisation nous utilisons également l’API existant de Google Maps pour renseigner les données liées à la position de l’utilisateur.
Le processus inverse a lieu quand l’utilisateur veut signaler un danger sur son application : l’application fait une requête à l’API REST Melckone (« POST »), qui demande à son tour (avec le langage approprié) à la base de données d’ajouter un item « dangers » afin qu’il soit stocké en mémoire. De même, l’API existant de Google Map interviendra pour renseigner les coordonnées GPS de l’endroit où l’utilisateur a défini un danger.
Peut-être avez-vous aussi entendu parler du back-office ? Il s’agit d’un espace de gestion des données. Pour ses administrateurs (très souvent à l’origine du projet d’application), c’est un moyen de communiquer avec l’API sans mettre les mains dans le code : il s’agit d’une interface visuelle où un administrateur peut retrouver toutes les données mais aussi les manipuler (c’est à dire les modifier ou encore les supprimer).
Par exemple, l’administrateur de l’application Melckone peut supprimer (“DELETE”) un danger qu’il juge inoffensif, en envoyant une commande à l’API REST qui la traduit pour qu’elle soit comprise par la base de données.
Finalement, on peut dire que le back-end correspond à la réflexion « mentale » de l’application : le code qui lui est associé permet de donner des règles logiques pour répondre correctement à une demande de l’utilisateur. Dans cet exemple, quand un utilisateur crée un danger, le serveur pourrait vérifier qu’un autre utilisateur n’a pas créé un danger du même type dans un rayon très proche. Et dans ce cas, le serveur préviendrait l’utilisateur (sur l’application, donc coté front-end) via l’API REST, en affichant l’existence du danger et demanderait directement à l’utilisateur de confirmer qu’il s’agit bien d’un autre danger que celui qui déjà connu.
Take home message : une application possède deux parties : le front (visible), c’est ce que les utilisateurs voient et la partie avec laquelle ils interagissent et le back (invisible), ce que les utilisateurs ne voient pas, l’espace central de gestion de données.
Pour fonctionner, la plupart des applications doivent impérativement avoir un back-end, déployé dans le cloud ou sur un serveur physique, une base de données et au moins une API, qui est la colonne vertébrale de l’application puisqu’il permet d’afficher des données intelligemment.