Comment créer un serveur d’API simulé en JavaScript

Développer et tester une fonctionnalité frontend peut être difficile, surtout lorsque le backend dont elle dépend n’est pas prêt. Cette dépendance à une API backend ralentit souvent le processus de développement.

Dans ce type de situation, créer une API simulée peut vous faire gagner beaucoup de temps en vous permettant de développer votre fonctionnalité indépendamment du backend et de tester plus facilement les scénarios dans lesquels votre API risque d’échouer avant d’être prête.

Dans cet article, vous découvrirez les serveurs d’API simulés, les outils permettant de créer des API simulées, comment les utiliser pour accélérer le développement et les tests, ainsi que la configuration d’un serveur simulé simple.

Qu’est-ce qu’un serveur d’API simulé ?

Un serveur d’API simulé est un serveur d’API fictif qui fournit des réponses réalistes aux requêtes qu’il reçoit d’un client. Il sert généralement de substitut à un serveur backend encore en cours de développement.

Un serveur d’API simulé imite une véritable API en utilisant des données fictives contenant des valeurs de réponse réalistes, mais dépourvues de nombreuses caractéristiques fonctionnelles et non fonctionnelles du composant d’origine, comme la persistance des données.

Les serveurs d’API simulés peuvent être utilisés dans différentes situations, notamment les suivantes :

• Développement : les serveurs d’API simulés suppriment temporairement la dépendance entre les équipes frontend et backend, ce qui leur permet de travailler, de développer et de tester leurs composants de façon indépendante.

• Tests : les serveurs d’API simulés facilitent les tests, étape essentielle du développement logiciel, en permettant à l’équipe frontend de tester ses fonctionnalités sans attendre que l’équipe backend développe une API entièrement fonctionnelle. Ils évitent également de polluer une véritable API avec des données de test : tous les appels de test sont adressés au serveur d’API simulé, et non à l’API réelle.

• Composants externes : les serveurs d’API simulés permettent aussi de simuler des dépendances externes lorsque vous utilisez des outils comme Storybook pour présenter des fonctionnalités frontend.

Bonnes pratiques pour les API simulées

Lorsque vous créez un serveur d’API simulé, gardez à l’esprit les bonnes pratiques suivantes :

• Une API simulée doit prendre en charge le même schéma et les mêmes interfaces que l’API réelle, afin de garantir des réponses plus réalistes.

• Si votre application a besoin de dépendances externes, votre API simulée doit également les simuler.

• Une API simulée doit prendre en charge le transfert des requêtes. Vous pourrez ainsi passer progressivement des réponses simulées aux réponses réelles, une fois l’API réelle développée.

• Une API simulée doit pouvoir reproduire les erreurs inattendues, les ralentissements et les saisies utilisateur non valides. Vous vous assurez ainsi que vos applications sauront gérer correctement ces situations.

Outils de simulation d’API

De nombreux outils permettent de créer des serveurs d’API simulés. En voici quelques-uns :

• Mock Service Worker (MSW) : Mock Service Worker est une bibliothèque de simulation d’API qui exploite la Service Worker API. Cette API permet à MSW d’intercepter les requêtes réelles et de renvoyer des réponses simulées en faisant office de serveur proxy. Les interceptions ont lieu au niveau du réseau : votre application ne sait donc pas que les réponses proviennent d’une API simulée.

• Postman : Postman est une plateforme dédiée à la création, à l’utilisation, aux tests et à la documentation des API. Elle permet également de créer des serveurs d’API simulés qui renvoient des données simulées enregistrées. Postman compare la configuration de la requête aux exemples enregistrés, puis renvoie les données correspondant le mieux à cette configuration. Son interface graphique interactive facilite la configuration d’un serveur Postman simulé.

• Mirage JS : Mirage JS est une bibliothèque de simulation d’API qui vous permet de créer et de tester une application JavaScript sans dépendre de services backend. Mirage JS facilite la création de scénarios dynamiques et rend ainsi votre API simulée plus réaliste. Grâce à cette capacité et à sa base de données en mémoire, Mirage JS offre une grande flexibilité pour créer des serveurs d’API simulés.

Créer un serveur d’API simulé avec Mirage JS

Dans cette section, vous apprendrez à créer un serveur d’API simulé simple avec Mirage JS.

Prérequis

Avant de commencer, vous devez disposer des éléments suivants :

• Node.js v16 ou version ultérieure installé sur votre système.

• L’IDE de votre choix.

• Des connaissances de base de React.js.

Pour suivre les étapes dans votre éditeur, commencez par cloner le dépôt GitHub du tutoriel.

Configurer votre serveur simulé

Exécutez les commandes suivantes dans votre terminal pour installer les dépendances nécessaires et démarrer votre serveur de développement :

1npm install
2npm run start

Vous devriez voir un widget animé, mais aucune fonctionnalité dans l’application. En effet, votre application essaie de récupérer des données auprès d’une API qui n’est pas encore prête. Pour accélérer votre développement, vous allez créer un serveur simulé.

Dans votre répertoire src, créez un fichier nommé mock.js et ajoutez le bloc de code ci-dessous :

1//mock.js
2import { createServer } from "miragejs";
3
4const createMockServer = function () {
5 let server = createServer();
6
7 return server;
8};
9
10export default createMockServer;

Dans le bloc de code ci-dessus, vous avez importé createServer depuis miragejs. Cette fonction démarre un serveur Mirage à partir d’un objet de configuration donné. Cet objet peut contenir des informations telles que les différentes routes gérées par votre serveur, une base de données simulée en mémoire et un espace de noms.

La fonction createMockServer se charge de créer et de renvoyer l’instance.

Créer une base de données simulée en mémoire

Ensuite, vous allez créer une base de données simulée simple à l’aide de la couche de données de Mirage pour stocker et renvoyer des données.

Modifiez votre fichier mock.js pour qu’il corresponde au bloc de code ci-dessous :

1//mock.js
2import { createServer, Model } from "miragejs";
3
4const createMockServer = function () {
5 let server = createServer({
6   models: {
7     todos: Model
8   },
9 });
10
11 return server;
12};
13
14export default createMockServer;

Dans le bloc de code modifié, vous importez également Model, la définition de base des modèles Mirage, depuis miragejs.

Vous avez ensuite transmis un objet de configuration à createServer. Dans cet objet, la propriété models est définie sur un objet et, dans l’objet correspondant à la propriété models, todos est défini sur model. Mirage créera ainsi une collection todos vide dans sa base de données en mémoire.

Initialiser une base de données en mémoire

Ensuite, vous allez ajouter manuellement des données à la base de données en mémoire à l’aide du hook seeds. Le hook seeds permet d’ajouter des données initiales à Mirage, afin que votre API simulée dispose de données à afficher au premier démarrage de l’application.

Pour ajouter des données initiales à votre base de données, insérez le bloc de code suivant sous la propriété models dans l’objet de configuration de createServer :

1    //mock.js
2   seeds(server) {
3    server.create("todo", {
4      id: 1,
5      title: "Reach out to a friend",
6      completed: true,
7    });
8
9    server.create("todo", {
10      id: 2,
11      title: "Make breakfast",
12      completed: true,
13    });
14
15    server.create("todo", {
16      id: 3,
17      title: "Text John Doe",
18      completed: false,
19    });
20  },

Dans le bloc de code ci-dessus, vous avez ajouté le hook seeds à votre objet de configuration. Le hook seeds reçoit une instance du serveur en argument.

Vous avez ensuite ajouté des données à votre base de données en mémoire en appelant la méthode create sur l’instance du serveur. La méthode create prend deux arguments : le nom au singulier (par exemple, « todos » devient « todo ») de la collection dans laquelle enregistrer les données, et les données à enregistrer.

Définir les gestionnaires de routes simulées

Ensuite, vous devez définir les gestionnaires de routes à l’aide du hook routes. Le hook routes permet de spécifier des gestionnaires pour chaque chemin disponible et chaque requête HTTP.

Ajoutez le bloc de code suivant à l’objet de configuration de createServer, juste sous le hook seeds, afin de définir les gestionnaires des appels à votre API :

1routes() {
2    this.namespace = "api/todos";
3
4    this.get("/", (schema, request) => {
5      return schema.todos.all().models
6    });
7  },

Dans le bloc de code ci-dessus, vous avez utilisé le hook routes pour définir un espace de noms global pour tous les gestionnaires de routes (api/todos), afin de ne pas avoir à le répéter dans chaque gestionnaire.

Vous avez ensuite défini un gestionnaire de route GET avec la méthode get, qui prend un chemin et une fonction de rappel. Dans cette fonction, l’application peut accéder à l’argument schema, qui permet d’accéder à votre base de données en mémoire, et à l’argument request, qui donne accès au corps de la requête.

Enfin, vous avez renvoyé tous les éléments todo de votre base de données en mémoire en appelant la méthode all sur schema.todos. Pour accéder au modèle en mémoire, ajoutez son nom à l’argument schema. La méthode all renvoie un objet Collection qui possède deux propriétés : modelName et models.

La propriété modelName correspond au nom de votre modèle, tandis que la propriété models est un tableau contenant les données initialisées.

Définissez le gestionnaire de route POST en ajoutant le code suivant à votre hook routes :

1  this.post("/new", (schema, request) => {
2       let attrs = JSON.parse(request.requestBody);
3       attrs.completed = false;
4
5       return schema.todos.create(attrs);
6   });

Dans la fonction de rappel ci-dessus, vous récupérez et analysez le corps de la requête à partir de l’objet de requête. Vous définissez ensuite la propriété completed sur false, car les nouvelles tâches ne doivent pas être terminées par défaut. Mirage attribue automatiquement un id unique à chaque nouvelle tâche en incrémentant l’id de la dernière tâche initialisée dans la base de données en mémoire. Enfin, vous avez utilisé la méthode `create`` pour ajouter la nouvelle tâche à la base de données.

Ensuite, définissez le gestionnaire de route PATCH en ajoutant le code suivant à votre hook routes :

1   this.patch("/:id", (schema, request) => {
2       let newAttrs = JSON.parse(request.requestBody);
3       let { id } = request.params;
4       let todo = schema.todos.find(id);
5       return todo.update(newAttrs);
6   });

Dans la fonction de rappel ci-dessus, vous récupérez et analysez le corps de la requête à partir de l’objet de requête. Vous extrayez ensuite la propriété id de l’objet params associé au corps de la requête. À l’aide de la méthode find, vous recherchez dans votre base de données en mémoire une tâche ayant un id correspondant. Enfin, vous mettez à jour la tâche à l’aide de la méthode update.

Définissez le gestionnaire de route DELETE en ajoutant le code suivant à votre hook routes :

1  this.delete("/:id", (schema, request) => {
2       let { id } = request.params;
3       return schema.todos.find(id).destroy();
4   });

Dans cette fonction, vous avez extrait la propriété id de l’objet params associé au corps de la requête. À l’aide de la méthode find, vous avez recherché dans votre base de données en mémoire une tâche ayant un id correspondant, puis appelé la méthode destroy pour la supprimer de la base de données en mémoire.

Voici à quoi devrait ressembler votre serveur simulé une fois terminé :

1import { createServer, Model } from "miragejs";
2
3const createMockServer = function () {
4 let server = createServer({
5   models: {
6     todos: Model,
7   },
8
9   seeds(server) {
10     server.create("todo", {
11       id: 1,
12       title: "Reach out to a friend",
13       completed: true,
14     });
15
16     server.create("todo", {
17       id: 2,
18       title: "Make breakfast",
19       completed: true,
20     });
21
22     server.create("todo", {
23       id: 3,
24       title: "Text John Doe",
25       completed: false,
26     });
27   },
28
29   routes() {
30     this.namespace = "api/todos";
31
32     this.get("/", (schema, request) => {
33       return schema.todos.all().models;
34     });
35
36     this.post("/new", (schema, request) => {
37       let attrs = JSON.parse(request.requestBody);
38       attrs.completed = false;
39
40       return schema.todos.create(attrs);
41     });
42
43     this.patch("/:id", (schema, request) => {
44       let newAttrs = JSON.parse(request.requestBody);
45       let id = request.params.id;
46       let todo = schema.todos.find(id);
47       return todo.update(newAttrs);
48     });
49
50     this.delete("/:id", (schema, request) => {
51       let id = request.params.id;
52       return schema.todos.find(id).destroy();
53     });
54   },
55 });
56
57 return server;
58};
59
60export default createMockServer;

Enfin, importez la fonction createMockServer dans votre fichier App.js, puis démarrez votre serveur simulé en appelant la fonction createMockServer dans votre fichier App.js.

Par exemple :

1//app.js
2import createMockServer from "./mock";
3
4createMockServer();

Si vous ouvrez votre application React, vous devriez voir l’application de gestion des tâches afficher les données initialisées depuis votre API simulée.

Vous pouvez maintenant tester votre application de gestion des tâches comme vous le feriez avec une véritable API backend.

Pour conclure sur les serveurs d’API simulés

Dans cet article, vous avez découvert les serveurs d’API simulés, leur utilité, les bonnes pratiques pour les créer et les outils qui peuvent vous y aider. Vous avez également appris à créer un serveur d’API simulé simple avec Mirage JS.

L’intégration de serveurs d’API simulés à votre processus de développement accélérera votre travail et vous permettra de travailler de façon autonome, pour un workflow plus efficace.