L’Outil Surpuissant pour Exploser ton Chiffre d'Affaires en 2024 !
GraphQL est-il adapté à votre architecture d'application ?
Vos applications mobiles et applications Web doivent obtenir leurs données quelque part, et ce quelque part est le plus souvent votre couche API. Ainsi, la façon dont vous concevez et construisez vos API aura un impact important sur le succès de vos applications mobiles et Web et donc sur le bonheur de vos clients.
Une décision clé dans la conception de votre couche API est de choisir REST ou GraphQL. Comme toutes les décisions architecturales, il n'y a pas de taille unique ; vous devez peser vos objectifs commerciaux, produits et techniques spécifiques par rapport aux mérites de ces deux alternatives populaires. Alors que REST met l'accent sur la création de points de terminaison uniques pour différentes ressources, GraphQL fournit un langage de requête expressif pour accéder aux ressources interdépendantes via un point de terminaison unique. Il existe de nombreux articles intéressants sur Internet qui tentent de comparer et de contraster de manière exhaustive REST par rapport à GraphQL, et je vous recommande de les lire tous ! 🙂 Cet article a un objectif plus modeste : nous discuterons de quelques critères à prendre en compte qui peuvent vous aider à déterminer si GraphQL pourrait vous convenir, ainsi qu'à votre architecture d'application.
Il est probablement prudent de dire que REST est la valeur par défaut. façon de créer des API à notre époque moderne. Le modèle RESTful fournit une suite de bonnes pratiques qui aident les concepteurs d'API à créer des API utiles et lisibles de manière assez standard. Il existe de nombreuses excellentes API REST qui alimentent Internet. Cela dit, GraphQL existe depuis une décennie maintenant, donc même s'il n'est toujours pas aussi largement adopté que REST, ce n'est certainement plus le petit nouveau sur le bloc.
Une caractéristique importante de GraphQL est qu'il est conçu. avec un schéma et un système de types à l'esprit. Cela a des implications importantes sur la façon dont votre application interagit avec votre API. Cette approche basée sur le schéma et le langage de requête expressif de GraphQL donnent plus de contrôle aux développeurs d'applications clientes. Cela peut faire une grande différence dans l'efficacité du processus de développement global ainsi que dans les performances et la qualité du produit final.
Voici quelques questions à vous poser lorsque vous évaluez si GraphQL pourrait être une bonne solution pour votre architecture d'application. :
Créez-vous un tout nouveau produit ou une preuve de concept ? Allez-vous beaucoup changer d'avis ? Vos besoins évoluent rapidement ? La présentation des données évoluera-t-elle et sera-t-elle continuellement itérée ?
Si tel est le cas, l'approche basée sur le schéma d'abord de GraphQL peut être très attrayante. Vous pouvez concevoir votre API GraphQL pour exprimer les données et les relations sans avoir à prédire à l'avance exactement comment les applications destinées aux utilisateurs consommeront vos données. Les développeurs d'applications peuvent ensuite choisir les données dont ils ont besoin quand ils en ont besoin. Cela permet d'ajouter et de soustraire facilement des fonctionnalités d'application sans avoir à refactoriser et à redéployer constamment vos API tout au long du processus de développement du produit. Cela peut vraiment accélérer votre processus de développement de produits et donc votre vitesse de mise sur le marché.
Créez-vous une application mobile hautes performances qui sera sensible aux restrictions de bande passante et aux connexions lentes ?
Si c'est le cas, il sera important d'optimiser quelles données vous récupérez et comment vous les récupérez. GraphQL offre au développeur d'applications clientes une grande flexibilité lors de la spécification des données à récupérer en un seul appel. Cela peut signifier parcourir une arborescence d'objets de référence en référence en un seul appel au lieu des multiples appels qui pourraient être nécessaires à l'aide des API REST. Et cela signifie également obtenir uniquement les bits de données dont vous avez absolument besoin pour que votre application fonctionne. Aucune erreur supplémentaire dans la réponse.
Les mêmes données doivent-elles être présentées de différentes manières dans l'application ?
GraphQL fournit à une application cliente un moyen simple de spécifier quels bits de données particuliers récupérer. De même, il existe de bonnes bibliothèques clientes pour la mise en cache des données afin que les données mises en cache à partir d'un appel puissent potentiellement répondre à de futures demandes de données qui se chevauchent.
Envisagez-vous d'utiliser un langage fortement typé dans votre application mobile ou Web ?
Si c'est le cas , cela devrait naturellement bien fonctionner avec l'accent mis par GraphQL sur les définitions de schéma et de type. Vous bénéficierez probablement de précieux avantages en termes d'efficacité pour les développeurs lors de la création et de la maintenance de votre application.
Gérez-vous beaucoup de données spécifiques à l'utilisateur ? La mise en cache périphérique (par exemple avec un CDN) de nombreux contenus non authentifiés est-elle une priorité faible pour votre application ?
Si tel est le cas, GraphQL pourrait être un bon choix. Bien que la mise en cache périphérique du contenu soit certainement possible avec GraphQL, sa mise en œuvre est légèrement plus compliquée qu'elle ne le serait avec les API REST. Cela est dû à la forte dépendance de GraphQL à la méthode HTTP Post et à la réponse HTTP 200. Si la mise en cache périphérique n'est pas une priorité, vous pouvez alors profiter des nombreux avantages de GraphQL avec peu de compromis. Si la mise en cache périphérique est une priorité pour votre application, vous pouvez toujours explorer à l'aide de GraphQL, mais assurez-vous simplement de répondre et de résoudre vos besoins de mise en cache dès le départ.
Il ne s'agit en aucun cas d'une liste exhaustive de considérations. Mais si vous avez répondu « oui » à quelques-unes de ces questions, vous souhaiterez peut-être explorer davantage l'utilisation de GraphQL pour l'architecture de votre application. GraphQL est peut-être fait pour vous.
Source link