Comment Debating GraphQL a fait parler nos développeurs frontaux et arrières

Développement chez CALLR

.@davypeterbraun expliquant pourquoi les télécommunications sont toujours d'actualité, et partout #ParisAPI @mailjetdev @meetupFR pic.twitter.com/X7xNikfeoe

— APPELEZ (@CALLR) 28 juin 2017

Quelques mots pour préparer le terrain : APPELANT est une entreprise de télécommunications. En termes de développement, nous avons affaire à des protocoles et à des normes exotiques. Le HTTP, c'est bien, mais qu'en est-il des PBX, H.323, SIP, ISDN, QSIG... ? Comme de nombreuses entreprises technologiques, nous générons, stockons ou déplaçons de nombreuses données sensibles. Cela signifie que notre personnel doit vraiment connaître son métier.

.@davypeterbraun « Les télécommunications sont un métier tellement spécialisé qu'il est préférable de faire appel à des experts : front, back et DevOps. » #ParisAPI

— APPELEZ (@CALLR) 28 juin 2017

Nous essayons d'y parvenir en adoptant une approche légèrement différente de celle de la plupart de nos pairs : au lieu de favoriser des développeurs complets complets, nous préférons une approche de niche. Nous voulions scinder notre équipe en opérations back-end, front-end et développement, et embaucher des personnes réellement spécialisées dans chacun de ces domaines. L'homme de la Renaissance ne fonctionne tout simplement pas pour notre modèle économique. Nous avons opté pour une équipe composée de : 3 développeurs back-end, 3 développeurs, 3 développeurs frontaux sur Angular. Bien entendu, la spécialisation entraîne un effet de silo, et les barrières de communication sont devenues inévitables entre les unités de développement. Nous essayons de limiter les frictions en investissant dans des managers équilibrés : le CTO et le responsable technique sont évidemment des personnes complètes, ils ont donc une bonne vue d'ensemble des missions et du stack. Nous avons également décidé de passer à un processus complet basé sur les récits d'utilisateurs, c'est-à-dire définir des composants multispécialités, notamment en utilisant des user stories impliquant les deux extrémités du spectre du développement en même temps. Enfin, nous utilisons JSON-RPC, bien qu'une version REST de notre API soit disponible pour le bénéfice de nos clients. Cela signifie également que nos développeurs (interface CALLR) sont les premiers utilisateurs de notre API JSON-RPC.

.@davypeterbraun « La mise à jour des SDK peut être fastidieuse, mais les avantages du JSON-RPC en valent la peine. » #ParisAPI pic.twitter.com/FKFeCBQYQA

— APPELEZ (@CALLR) 28 juin 2017

Lancer le défi — GraphQL au goût des bières

Passons donc au cœur du sujet : le débat sur la question de savoir si GraphQL pourrait avoir un impact positif potentiel sur CALLR. Le sujet a été abordé par des spécialistes du front-end parce que GraphQL appartient à l'écosystème Facebook des hype techs, alias le triumvirat React/Relay/GraphQL :

• React est une bibliothèque JS pour créer des interfaces utilisateur
• Relay est un framework fournissant des fonctionnalités de récupération de données pour les applications React, agissant comme une sorte de accélération du mélange entre eux,
• et... GraphQL

La grande question était la suivante : GraphQL est-il vraiment une nouvelle version de JSON-RPC déguisée ? Ne faisions-nous pas déjà quelque chose de très similaire ? Comme le dit le proverbe, ne répare pas ce qui n'est pas cassé. C'est vrai, GraphQL et JSON-RPC ont quelques points communs... comme un point de terminaison POST unique qui rappelle évidemment beaucoup les API RPC

« Tout comme JSON-RPC, avec #GraphQL vous ne publiez qu'une seule fois » - @davypeterbraun #ParisAPI @mailjetdev @meetupFR pic.twitter.com/AryC4KillM

— APPELEZ (@CALLR) 28 juin 2017

... et ils offrent tous deux, d'une manière ou d'une autre, la possibilité de récupérer des données provenant de plusieurs sources en un seul appel (on pourrait utiliser une requête par lots dans JSON-RPC). Mais les Pro-Graphqlers avaient également quelques points intéressants à faire valoir., à savoir que GraphQL pourrait :

Alors, arrondissons :

Par souci de transparence, nous n'avons pas encore configuré GraphQL sur notre stack. Mais c'est maintenant quelque chose que nous pouvons envisager (après avoir évalué les coûts cachés, les risques, etc.). C'est amusant de voir comment nous avons bouclé la boucle depuis les débuts des pages Web rendues basées sur des bases de données, c'est-à-dire :

• boucle de rendu pour afficher une page à partir des résultats des requêtes SQL (dans le passé, je parle d'un mélange PHP/HTML)
• boucle de rendu pour rendre un DOM à partir d'un AST né de données brutes (le présent)

C'est encore plus drôle que, selon la personne à qui vous demandez, la partie accès aux données soit soit presque parfait et n'a pas besoin d'être réinventé, soit est en pleine mutation depuis le premier jour malgré d'excellents ORM et optimisations, et que son domaine de problèmes devrait être redéfini pour prendre en compte les besoins des applications modernes. Ce que j'ai retenu de cette expérience, c'est qu'à la suite d'une discussion informelle sur les bières, nous avons abouti à une étude de cas intéressante sur la manière d'accroître notre efficacité et de mieux travailler en groupe et en équipe, malgré nos différences. Le noyau de la sagesse que je transmettrais est n'hésitez pas à participer à ces discussions et à vraiment entrer dans le vif du sujet de tout choix lié à la technologie l'entreprise fabrique. Ce n'est qu'en vous y mettant que vous pourrez vous faire une idée complète des avantages, des inconvénients et des implications futures de la modification de votre infrastructure technologique, de la modification d'un processus ou de toute autre chose. Alors, mets-toi à parler ! Pour plus de détails, vous pouvez consulter la présentation diapositives ici ainsi que notre Moment Twitter.[cta href= » https://www.callr.com "txt="Vous avez besoin d'un fournisseur de services vocaux et SMS ? » btn="Consultez notre API "]