Avez-vous déjà entendu parlé de la méthode Serverless Mobile Application ? Dans ce post je vous présente une technique pour connecter votre application mobile au cloud à moindre effort.

Vous souhaitez créer votre application mobile connectée

Vous connaissez déjà le développement mobile ou vous n’avez encore jamais compilé votre propre application ? Peu importe, je vais cadrer le contexte pour que tout le monde comprenne.

Pour développer une application mobile, il existe plusieurs technologies. Je les détaillerai dans un poste ultérieurement, ce n’est pas ce qui nous intéresse ici. Ce qu’il faut retenir c’est qu’une application mobile, pour être connectée, c’est comme un site web : il faut un serveur qui centralise les données. Et la problématique dans tout ça ? Développer une application mobile et développer un serveur c’est comme une vache et une mouche : c’est complètement différent et pourtant ça va toujours ensemble.

Quel est le rôle du serveur back-end vis à vis de l’application mobile ?

Le serveur back-end sert à stocker et fournir les données à l’application mobile. Toutes les données sont recensées au même endroit, dans le serveur, et l’application mobile n’a qu’à interroger le serveur pour obtenir les données puis les afficher correctement à l’utilisateur.

De même, toute l’intelligence métier et tous les algorithmes doivent être fait par le serveur, et non par l’application mobile. Cela pour diverses raisons :

• La première et la plus importante : pour centraliser l’effort. Si demain j’associe un site web à mon application mobile, je n’aurai qu’à brancher le site sur le même serveur que mon application, sans avoir à recréer les algorithmes de logique métier. De même avec une application Android, et une iOS.
• La seconde, et pas moins importante que la première : les algorithmes métier ne seront codés qu’une seule fois, dans le serveur. S’il y a un bug ou des modifications à effectuer, le travail sera fait une seule fois, à un seul endroit, et sera répercuté partout (applications mobiles, éventuels sites web, etc…)
• Enfin, un serveur est une machine disposant de puissant moyens de calculs, contrairement à un smartphone qui a des capacités de calculs bien inférieurs : donc plus lent.

En résumer : le serveur back-end est le cerveau, c’est lui qui réfléchie. Quand à l’application mobile, elle n’est là que pour servir d’interface entre l’utilisateur et les données.

 Comment fonctionne un serveur back-end classique ?

De manière très classique, un serveur back-end est constitué d’une base de données, et d’une API faisant le lien entre la base de données et l’extérieur du serveur. En disant l’extérieur, j’entends votre application mobile, votre site web, ou n’importe quelle autre requête isolée. N’oubliez pas que des robots de pirates tournent en permanence pour essayer des adresses au hasard, et une fois qu’ils ont trouvé une adresse valide, essaient les failles de sécurité connues pour tenter de pirater vos données.

Techniquement, l’extérieur peut accéder directement à la base de données en disposant des identifiants adéquats, sans passer par une API. Cela permet d’économiser le coup de production d’une API. Mais cela est fortement déconseillé ! D’une part car cela force le développeur à créer la logique métier en dehors du serveur, mais surtout car cela ouvre des portes permettant de pirater la base de données.

En résumé : un serveur back-end comprend une base de données, et une API qui sert de porte d’entrée et/ou de sortie.

Quel moyen pour réduire l’effort de mise en place d’un serveur back-end ?

Je souhaite vous parler ici d’une technique particulière, appelée « Serverless Backend for Mobile Application ». James Montemagno l’a parfaitement détaillé sur le blog Xamarin. Cette technique n’invente rien, elle permet juste d’utiliser les derniers outils de Microsoft  afin de s’affranchir d’un maximum de travail, tant lors de la création que pour le développement ou la maintenance.

Il s’agit d’utiliser les derniers outils du moment, à savoir Microsoft Azure, afin de ne coder que le stricte nécessaire. Tout le reste étant pris en charge automatiquement par Azure. Je m’explique : des actions comme « vérifier les droits d’un utilisateur » ou « gérer un pull de thread permettant de traiter les unes à la suite des autres toutes les requêtes entrantes dans le serveur » sont des actions génériques à tout projet. Cela ne sert à rien de les re-développer à chaque fois. Au contraire, le stricte nécessaire pour une application est la logique métier, les algorithmes propre à l’application, les accès à la base de données etc…

Utiliser la méthode Serverless Backend for Mobile Application permet de ne coder que la logique métier. Tout le reste étant pris en charge automatiquement par Microsoft Azure. Il n’y a même pas besoin de coder sur son ordinateur et mettre le code en ligne : on peut coder directement dans le navigateur internet ! Cela simplifie et accélère considérablement la création d’API pour son projet d’application mobile.

C’est parti, je veux essayer ! Par où commencer ?

Bravo ! Je suis content de vous avoir convaincue d’essayer ! Mais avant tout, je vous invite à lire mon retour d’expérience sur le projet Gotago pour avoir un aperçu des avantages et des inconvénients de cette méthode. Toute méthode est indiquée dans certain cas de figure, comme elle peut être contre-indiquée dans d’autres circonstances. Celle-ci, en particulier, est conseillée pour des projets plutôt court, ou des POC.

Pour commencer, il faut avoir un compte Microsoft Azure. Tout est gratuit jusqu’à un certain seuil (que je n’ai pas dépassé en plusieurs mois de développement).

Dans Azure, vous pourrez créer, héberger, et administrer votre base de données en SQL Server. Vous pourrez utiliser un outils de visualisation de base de données de votre choix. Personnellement, j’utilise Visual Studio.

Pour ce qui va vous servir d’API, vous créerez une Function App. Cette dernière sera constituée d’HTTP Triggers. Un Http Trigger est un script exécuté, comme son nom l’indique, par une requête Http à une URL précise. On peut faire un GET ou un POST, et utiliser du JSon pour transférer des données par exemple. Vous créerez votre logique métier dans ces Http Triggers, et vous utiliserez les URL depuis vos applications mobiles ou vos sites web pour envoyer ou récupérer du JSon. Et voilà, c’est tout ! Rien de plus à faire.

Un petit exemple avant de finir

Voici un petit exemple d’un Http Trigger dans Azure. Je vais réaliser une API permettant de vérifier la validité d’une adresse email d’utilisateur. Par exemple quand un utilisateur s’inscrit dans votre application, il ne doit pas utiliser une adresse mail déjà utilisée.

Je vais avoir une URL : https://api-monexemple.azurewebsites.net/api/isemailvalid

En POST, je vais passer une chaine JSON : { email : « mon@email.com » }

En résultat, l’URL renverra une chaîne JSON avec l’adresse email vérifiée, et le résultat de la vérification : { email : « mon@email.com », isValid : true }

Je pourrais ensuite effectuer une requête HTTP vers l’URL depuis n’importe où ! Mon application Android, mon application iOS, mon site web… De plus, l’algorithme de vérification d’email peut changer à tout moment, la seule modification à faire sera sur l’API.

   Interface de codage directement dans le navigateur

La fenêtre ci-dessous représente mon navigateur internet dans lequel j’ai codé mon HTTP Trigger. On voit le code en haut à gauche, la fenêtre de test à droite, et la console en bas à gauche.

La fenêtre de code me permet, comme vous l’aurez deviné, de coder mon API. Je fais les « includes », je décrypte le body si c’est une requête POST, j’appelle la fonction pour le code métier, et j’envoie une réponse avec le résultat du code métier.

La fenêtre de test me permet de simuler un appel à l’API complètement personnalisé. C’est très pratique pour tester son développement ! Sans cette fenêtre, je devrai lancer mon application Android ou iOS et cliquer le bouton qui effectue l’appel API… Une fois que l’appel a été effectué en test, j’ai directement le résultat en dessous, en vers, avec la chaîne de retour associée.

La fenêtre de console, quant à elle, donne toutes les informations sur le code. Si le code compile ou pas, où sont les erreurs… On a également les traces en cas d’appel à l’API. On pourra retrouver ces traces à un autre endroit : dans la fenêtre de monitoring. Cette dernière offre un historique de tous les appels effectués à l’API. C’est indispensable pour maintenir son service.

   Code métier de l’API

La fenêtre ci-dessous présente le code métier qui vérifier mon adresse email. J’ai retiré les fenêtre de test et la console pour plus de lisibilité :

Le code vérifie dans un premier temps le format de l’adresse email.

Ensuite, l’API se connecte à une base de données, et effectue une requête SQL permettant de vérifier si un utilisateur avec la même adresse email existe déjà. La base de données SQL peut être hébergé, gratuitement jusqu’à un certain seuil, sur Azure. Elle peut tout à fait être hébergée ailleurs aussi.

Enfin, voici la classe permettant de gérer le JSON de la requête HTTP :

En utilisant cette classe et le package Nuget Newtonsoft.Json, je peux sérialiser et desserialiser du JSON en une simple ligne ! Extrêmement pratique n’est ce pas ?!

Et vous, quelles méthodes utilisez-vous pour vos créer API ? Quelles architectures utilisez-vous pour vos plateformes web et/ou mobile ?