GraphQL est un peu agaçant
(news.ycombinator.com)- GraphQL est excellent, mais semble un peu survendu
- Les développeurs débutants à intermédiaires semblent se mettre à utiliser GraphQL après avoir regardé YouTube, mais ça paraît être une erreur
- Avantages
- Permet de décrire facilement les données voulues
- Économise de la bande passante. On peut récupérer en une fois exactement ce qu’on veut
- Facilite la création de documentation pour les consommateurs de données
- Permet d’utiliser plus facilement les abonnements
- Rend possible le regroupement des appels API
- Inconvénients
- C’est pénible à utiliser en pratique. Selon le backend utilisé, si rien n’est généré dans votre langage, il faut gérer deux systèmes de types ou plus
- Ne prend pas en charge les maps/tables/dictionnaires. C’est vraiment énorme. Même si on n’en a pas envie, on finit par utiliser quelque part
{[key: string] : T} - Il n’existe pas de méthode claire pour le versioning d’API. Au final, on finit par faire des choses du genre MyQueryV1.01 MyQueryV1.02 MyQueryV1.03
- N’utilisez pas GraphQL si vous ne traitez pas l’ensemble de solutions/problèmes que Facebook avait en tête pour GraphQL
- Quels conseils avisés d’autres développeurs seniors pourraient aider les développeurs juniors à ne pas tomber dans ce bourbier ?
Commentaires sur HN
- Le plus gros problème de GraphQL, c’est qu’il faut travailler pour se défendre contre les attaques DOS ou contre ceux qui essaient de télécharger toute votre base de données.
- Il est très facile de créer des requêtes qui imposent une charge excessive à votre système.
- Pour voir ce qu’il faut mettre en place, il suffit de regarder Shopify. Ils appliquent du rate limiting sur le volume de données retournées, et gèrent aussi les curseurs et la pagination. Contrairement aux beaux exemples de GraphQL qu’on voit sur Internet, leur schéma est énorme et peu élégant
- GraphQL est un excellent moyen de résoudre les problèmes d’organisation que rencontrent les grandes entreprises tech
- Par exemple quand l’équipe qui maintient l’API et l’équipe qui demande des changements sont différentes
- Quand l’organisation est grande, il faut parfois attendre une éternité pour obtenir une modification, et GraphQL réduit ce besoin
- Dans une petite organisation, ne suffit-il pas simplement de développer directement ce qu’il manque ?
- Que ce soit intentionnel ou non, GraphQL permet aux développeurs frontend d’être découplés des demandes adressées aux développeurs backend, et donc d’avancer plus vite
- Si un développeur backend construit le modèle de données et l’expose via GraphQL, un développeur frontend qui n’a jamais rencontré ce développeur backend peut s’en servir immédiatement
- On peut modifier à la volée ce qu’on interroge et récupérer ce qu’on veut
- Cela permet à tout le monde d’aller vite
- Mais moi, en tant que développeur backend, je déteste vraiment GraphQL
12 commentaires
GraphQL est un peu agaçant. Pas extrêmement agaçant, mais quand même un peu. Cela dit, comme il réduit clairement le coût de communication entre les membres de l’équipe, il est plus efficace de régler les aspects agaçants pendant ce temps-là. Et franchement, c’est vraiment moche. Mais je recommande quand même d’utiliser GraphQL. Parce que personne ne sera d’accord pour utiliser tRPC. La plupart des gens refusent une technologie sur des idées préconçues sans même l’avoir vraiment essayée, et pour résoudre ça il faudrait l’imposer avec une autorité considérable. On peut le faire pour une ou deux technos, mais si on force tout, on y perd plus qu’on n’y gagne, donc ce n’est pas possible... Au final, le niveau le plus acceptable qu’on peut espérer pour convaincre, c’est GraphQL, hélas. Cette REST de merde, ça c’est vraiment une mauvaise technologie préhistorique qui coûte énormément en communication, hélas.
C’est la première fois qu’un article sur GeekNews me pousse à créer un compte. J’ai laissé une réponse à la partie The bad.
Il y a sans doute des avantages et des inconvénients vus respectivement côté client et côté serveur, mais quand on regarde l’ensemble, même en comprenant que la plus grande value proposition de GraphQL est que son schéma vient combler la couche d’abstraction manquante entre le serveur et le client, dire qu’on envisagerait REST pour un produit généraliste me semble personnellement un peu daté.
The bad
two or more type systems if there are no code first generates in your language
En d’autres termes, si on l’utilise correctement, c’est bien, non ? La génération de code et ce genre de choses, ce n’est même plus vraiment un problème aujourd’hui vu à quel point le tooling a progressé.
some pattern where you don't want to allow this but for the majority of situations working with json api's you'll end up with a {[key: string] : T} somewhere
C’est aussi mentionné dans Production Ready, mais si on exploite les avantages du Type System, ça ne me semble pas être un point qui demande vraiment réflexion. Au lieu d’un key: string, il suffit de définir des champs précis.
À l’origine, GraphQL est versionless....
Don't use Graphql unless you're managing a solution/problem set that facebook intended graphql for Invest your time in a simpler solution then running to GraphQL first
On dirait un peu comme dire qu’il ne faut pas utiliser React si on ne résout pas le type de problème que Facebook cherchait à résoudre.
Bonjour, ce sont de bonnes paroles. Est-ce qu’on pourrait faire connaissance ? J’ai besoin de personnes qui pensent la même chose. C’est vraiment très difficile de convaincre les autres (les membres de l’équipe).
Haha, j’ai vu le commentaire un peu tard..!! Sur le Slack GraphQL Korea, j’utilise le pseudo Alucard :)
J’ai adopté GraphQL assez tôt, et à l’époque les explications étaient surtout centrées sur le backend. Du coup, j’ai l’impression qu’on en est venu à penser que c’était quelque chose de bien pour le backend.
Après avoir galéré et tâtonné sur pas mal de choses, quand des personnes arrivées plus tard dans l’entreprise ou des candidats en entretien me posent la question, j’explique que c’est difficile pour le backend, mais que c’est bien pour le frontend. :)
#Mais moi, en tant que développeur backend, je déteste vraiment GraphQL
Je compatis..
L’expression « au bon endroit, au bon moment » me vient immédiatement à l’esprit.
C’est pour ça qu’on utilise GraphQL. La spécification GraphQL indique aussi explicitement que c’est destiné au frontend 1
Moi aussi, j’ai commencé à utiliser GraphQL dans une nouvelle startup, et j’ai clairement l’impression que je dois communiquer moins souvent qu’avant avec les ingénieurs frontend au sujet de l’API.
Du point de vue d’un ingénieur backend, il y a effectivement des problèmes auxquels on ne pense pas avant d’utiliser GraphQL en pratique, et ça peut être assez pénible, mais ça me semble quand même bien mieux que de se casser la tête à essayer de concevoir une bonne API REST.
Aucune technologie n’est parfaite ! Je pense qu’une techno vaut la peine d’être adoptée si on en a vraiment besoin, ou si elle résout un problème plus important, au point que le coût nécessaire pour compenser ses inconvénients reste acceptable. La pertinence d’une technologie ou d’un outil dépend toujours du contexte de son utilisateur.
D’un autre côté, j’ai aussi l’impression que l’une des raisons pour lesquelles GraphQL est critiqué, c’est peut-être l’image de « simplicité » qu’il essaie de véhiculer.
Au début, quand GraphQL est arrivé et qu’on lançait des projets POC, il n’y avait aucun moteur qui prenait correctement en charge le multipart, donc je me souviens que c’était assez pénible…
Moi aussi, depuis un moment, quand je vois qu’on utilise GraphQL sur de petits projets, je me dis souvent que c’est vraiment surdimensionné… Visiblement, tout le monde pense plus ou moins la même chose.
Je n’ai traduit que les premiers commentaires. Il y en a plus de 400, donc c’est difficile de tous les lire.