Reprise du message précédent :

Ouais.

Ça fait chier.

Salut pluvieux.
Ici on a beau temps.

OK, je n'avais jamais entendu parler de ce truc. Le principal défaut de GraphQL, c'est son nom. On s'imagine que c'est une base de données graphe, ou quelque chose dans le genre, alors que ça n'a absolument rien à voir.
 
Mais sinon j'ai une question: si le client peut demander ce qu'il veut (dans la limite du schéma), qu'est-ce qui limite les requêtes abusives qui feraient tomber le serveur ? Je sais qu'on peut faire du déni de service sur du REST en multipliant les requêtes, mais c'est un peu plus compliqué, il faut des centaines de clients pour cela, alors que là il suffit d'une seule appli mal codée qui demande la terre entière à chaque requête.

Classe ! T'as combien de moteurs ? Un par roue ? (au vu des loupiotes, j'imagine que oui)

 
Excellent!
 
Le contrôleur que tu utilises, c'est quoi à la base? (le seul endroit où j'ai vu ce genre de truc c'est dans des bagnoles genre BM ou merco, mais j'ai du mal à croire que t'en ai cannibalisé une pour ça )

Un truc de ce genre: https://en.wikipedia.org/wiki/3Dconnexion

On fait du GraphQL dans ma boîte.  
Je pense que c'est lié à la façon dont c'est implémenté ici mais je trouve ça à chier : problèmes de sécurité d'accès aux données, de performance car les devs front peuvent requêter la base comme ils veulent, etc.  
Je n'ai pas encore pris le temps de regarder la théorie mais ici c'est pas foufou.  
Déjà des devs back qui font du SQL optimisé c'est pas tous les jours, alors des devs front à qui t'ouvres l'accès à la base via une API HTTP, ça m'excite pas

Pourtant ça me semble bien un graphe, surtout quand il est construit sur une base relartonnelle: je navigue d'une collection à l'autre en passant par les clés étrangères

Le client est authentifié, donc ça limite la casse et on sait où regarder
il y a bien sûr un système d'authentification et d'autorisation

Qu'est ce que ça change par rapport aux même dev qui font la même chose ? A part :

• L'espoir que les dev PHP connaissent SQL
• Le fait de pousser à faire une grosse requête plutôt que 22 appels Rest,

Et je ne parle pas des pages courantes types données tabulaires triable/filtrable/paginée qui sont une purge a implémenter en rest classique :
Je prends les choix de l'utilisateur> j'en construit une requête > je l'envoi au serveur > le serveur la vérifie , la traite , renvoie la réponse > je mets à jour le resultat côté client en gérant la concurrence de requêtes/réponses

La c'est packagé, pas besoin de réinventer la roue. Sans exagérer , avec moins de 100 lignes de code, j'ai mon tableau en vue qui fait le job (seule dépendance : le client graphql apollo)

Les problématiques de mise en cache hors connexion deviennent aussi beaucoup plus simple, que ce soit en web ou en mobile. Rendre une page reactive devient aussi plus simple (ça c'est vraiment à utiliser avec parcimonie parceque ça fait du polling dans la base de données), mais le code des liveboards va devenir trivial : une souscription + vuejs qui vont faire la partie pénible, et on va pouvoir se concentrer un peu plus sur le contenu et l'UX

La propal que je vais faire ici c'est

- graphql pour lire les données en général
- 3-5 rôles en mode grosse maille pour limiter un peu l'accès au donnée en lecture (passager, gestionnaire, admin, système embarqué, système)
- on conserve le fonctionnement actuel pour les modifications ( des services PHP) plutôt que d'utiliser les mutations graphql
- quelques api rest pour les cas spécifiques de lectures qui seraient trop complexes à sécuriser

A long terme : migration du monolithe services PHP vers des services plus digestes et plus modernes (pas des microservices non plus )

A noter que chez nous 1 install = 1 base de données = 1 client, donc la problématique de gestion des droits est gérable.
et on a déjà un serveur d'auth qui nous constuit de beaux JWT, à intégrer comme ça : https://hasura.io/docs/1.0/graphql/ [...] n/jwt.html

Ben c'est l'usage que je fais de graphql
(Oui parce qu'avec des ilike %nico% au milieu ça ressemble quand même au SQL)

Sauvage et gg

Bon apparemment, c'est les deux slots DDR du channel B qui marchent pas.
 
Avec n'importe quelle barrette dans le slot A2 ça marche, avec la même barrette dans un des slots B ça plante.
 
Le slot A1 est inaccessible parce qu'il a monté le ventirad du CPU dans une position qui coince avec le radiateur de la RAM.... Et j'ai pas de pâte thermique sous la main.
 
Déjà on va updgrader le bios, dans le changelog ils parlent d'amélioration de la stabilité RAM... Et sinon, la CM av partir en garantie

GraphQL permet au requêteur de créer des compositions plus ou moins arbitraire, donc t'as un gros risque de générer des cas pathologiques, même sans être nécessairement malicieux. Avec un système plus classique, le requêtage est fixe et c'est la paramétrisation qui change, donc il y a moins de chances que ça se pête la gueule et c'est plus facile à tracker & optimiser.

GraphQL est clairement avantageux côté front parce-que ça t'évite de te faire chier à toucher au back (ou pire à l'attendre), en tout cas si ce que tu veux est déjà présent dans l'API (pas toujours le cas), mais c'est pas anodin.

Dans un monde idéal je te rejoins
là, les requêtes en PHP sont faites par l'ORM donc de mon point de vue c'est un peu le même problème

Ceci dit vous avez raison, surtout qu'on a déjà des perfs qui ne sont pas optimales sur le front actuel,  il faut que je prépare des tests de performances en même temps pour encadrer le dev. J'imagine avec un budget "temps" sur un serveur de données sous dimensionné.
Je pense même qu'il doit y avoir moyen de le comparer face au temps de réponse de l'actuel.

dites, sur le PC du petit (qui tourne pour le moment avec une seule barrette de RAM), on a MaJ le bios (ça n'a rien changé), mais on a constaté que la RAM est à 2133 Mhz alors que c'est de la DDR4 3200
 
On peut monter la fréquence de la RAM sans se poser de question, ou c'est plus sioux que ça? J'avoue, là, je suis largé!

Justement non, dans un monde idéal où tout le monde est gentil et personne fait de bêtises c'est pas un problème.

Absolument pas. Tes requêtes faites par l'ORM elles sont plus ou moins fixées et généralement "plates", et il est possible mais généralement rare et difficiles de créer des cas pathologiques depuis le front. Beaucoup plus difficile que via graphql en tout cas.

pour moi la DDR4 3200 est a 1600Mhz, donc elle est déjà pas mal overclockée (moyennant les cas)  
 
ça peut expliquer qu'une barette de ram fasse la gueule

 
ah ok J'ai pas touché au bios, j'ai tout laissé en automatique.
 
Après le symptôme est clair : quand on met une barrette en B1 ou B2, le PC n'arrive même pas au bios.
 
Donc j'imagine que le réglage est déterminé par le PC ?

et les dev PHP savent faire des requêtes
j'ai vu des gens faire des aggolmerat en php parceque c'était plus simple ( groupement par mois glissant)

Sauf erreur de ma part  les requêtes qui vont faire peter une base de données sont

• celles de skeye (:o)  avec plein de logique métier. (genre des jointures sur des case , des having sur des count(distinct de batard))  et ça c'est  imbitables a écrire en graphql,
• Les requêtes qui ont beaucoup de résultats, et le navigateur va se suicider probablement assez vite

Les requêtes classiques du type "j'ai une collection, je vais chercher 30 lignes dans une autre tables en suivant les clé étrangères"x10  sont assez indolores pour la base de données(modulo le volume retourné bien sûr) , et sont gérées de manière très similaire par l'ORM

tu as essayé de la forcer en 1600 avec une barette puis de remettre l'autre ?

Non tiens.

Pour moi c'est super facile justement, suffit de faire un peu de nesting dans tes collections (surtout si elles sont co-récursives) et tu te retrouves avec une explosion combinatoire, et ça peut être encore plus problématique si ton resolver est "intelligent" et va "optimiser" le fetch récursif naif en un cross join qui explose ta db.

Et là encore, c'est pas la vue malfaisante de la chose. Si l'API est publique, tu vas avoir des gens qui vont générer du graphql pour essayer de faire exploser ton truc, que ce soit "imbitable à écrire en graphql" va pas trop les gêner

Cf https://www.apollographql.com/blog/ [...] 30a324a6b/ pour plus d'infos.

Ce qui t'aide pas trop si ça a déjà suicidé ton serveur.

Bien sûr, mais l'intérêt de graphql c'est que t'es pas limité à des trucs hardcodés de ce style

En général le serveur SQL est moins accessible à des utilisateurs que le serveur web ou n'importe quel client HTTP va pouvoir jouer avec ton API
 
Et oui c'est un énorme confort pour le front (au détriment de plein de choses) mais c'est parce que ces fronts sont des fullstacks refoulés

Et la recherche de la productivité n'est pas ce que je recherche dans mes équipes. Je privilégie la maintenabilité à long terme et la qualité (ces notions ne sont pas forcément incompatibles en revanche, suivant les choix technologiques qu'on fait).
 
Les requêtes SQL (en natif ou via ORM) elles passent en review en PR. Les requêtes HTTP faites par des petits malins qui auront vu qu'il y a une API GraphQL, ça passe pas en review.
Donc ça te fait une augmentation considérable de la surface d'attaque je trouve (en terme d'exposition de données et de perfs).

pour le lien, c'est une mine d'information  
 
La taille des requêtes est exactement le même problème avec les points REST qui génèrent ces mêmes tableaux / extraction statistiques . Si plusieurs utilisateurs demandent un export de tous les tickets de bus vendu pour une region + les voyageurs et leurs profils d'autorisation . A noter qu'hasura cloud permet de limiter l'api sur le nombre de requetes ainsi que la profondeur : https://hasura.io/docs/1.0/graphql/ [...] -api-limit , mais pas la version gratuite
 
Effectivement, je n'avais pas envisagé le côté api publique.  GraphQL va simplifier pour un tiers la découverte de l'api de manière non officielle, alors que les endpoints REST sont suffisament bordeliques pour être complexes à découvrir complètement.

ok pour la review,  et ça marche très bien sur les requetes simples/moyennes. Mais franchement, j'ai un peu  plus de mal à leur faire confiance sur les requêtes multi paramétrées  (conditions, filtres, ...) telles que celle qui sont utilisés pour des tableaux paramétrables . Et c'est une part énorme de l'app.
De plus l'usage de l'ORM cache une part importante de la complexité , les requetes ici sont remplies de fonction magiques qui génèrent des paramètres customs qui sont ensuite balancée au SGBD , hydratée (avec des jointures magiques/masquées), retravaillées à grand coup de foreach et repassée en JSON

edit : en fait, je n'ai jamais été fan des ORM, et ça se confirme, et ceux que j'ai vu cachent des problèmes simples et ne résolvent pas grand chose dans les cas complexes. Le seul intérêt serait de changer de SGBD au vol, mais sérieux, qui fait ça ? Au moins avec GraphQL, tu résoudx quelques problèmes en te posant la question des données nécessaires là ou elles sont utilisées et une seule fois, pas a 4 endroits dans ta stack

Reprenons dans l'autre sens, histoire que je vois les deux côtés, avec un cas simple

Tu as une page qui liste des voyageurs, avec des filtres sur les 5 colonnes et des tris

Tu as une page qui récapitule les données d'un voyageur
Elle contient des donnes de la table voyageur, de ses profils, des comptes web rattachés (papa maman par ex), et de 5 autres tables liées avec peu de lignes + l'historique des voyages  (jusqu'a plusieurs milliers)

Controleur 1 prends donc les paramètres de tri /fitlre et
Aujourd'hui le controleur fait quelques grosses requêtes en limitant a 20 voyages, balances ça a un template qui sors du HTML. Il y a ensuite eu une évolution pour permettre de paginer les tickets sans recharger toute la page

Donc j'ai 3 contrôleurs : 1 pour la liste des voyageurs avec une dizaine de paramètres ( tris, filtres, pagination), un qui crache la page du voyageur, et un de ticket qui est similaire mais pas trop au premier ( pas les mêmes colonnes, pas les même filtres). On parle de contrôleurs qui font des centaines de lignes pour la recup et la mise en forme des champs.

Est ce qu'il y a mieux ?

Pas exactement, ça c'est la taille des réponses, la taille des requêtes c'est qu'en graphql t'as énormément de flexibilité dans la complexité de composition de ce que tu demandes. Donc beaucoup plus de capacité à faire exploser la taille des réponses.

Vrai, mais tu peux de toute manière pas partir du principe que tes endpoints vont rester inconnus. Le problème est plus qu'avec graphql une fois que t'as mappé la structure des types du système tu peux commencer à les composer entre eux, alors qu'avec un RPC plus classique t'es limité à la complexité intrinsèque de chaque procedure.

Après je dis aucunement que graphql c'est le mal et qu'il faut pas en faire Juste que si ça résoud des problèmes, ça en apporte aussi (surtout si c'est une API externe, c'est moins problématique si c'est purement interne même si c'est pas complètement anodin), et il faut en être conscient.  Et ça dépend aussi très fortement de tes types & de leur organisation (en gros de tes queries et de la flexibilité que tu offres dans les sous-accès).

No comprendo la questiono

Tu utilises pas tokei

rati pr0n: https://www.youtube.com/watch?v=UXnEzwJpbBg

Jubi, tu viendras faire le faisceau, comme je suis développeur ça serait beaucoup trop cher d'utiliser mon temps pour faire ça.

j'en avais vu certains, mais j'en avais minimisé d'autres  

conaissais pas
bien sur ne quotez pas les chiffres sur la base de code, je les vire ce soir  

Pas compris non plus ce que tu attendais de nous
 
Sachant que s'il n'y avait que moi, on ne ferait pas de SPA hein Du HTML rendu server-side en PHP c'est extrêmement robuste et maîtrisé, la stack techno change pas tous les 4 matins, ça laisse de la place à du JS bien fait pour faire du progressive enhancement, côté recrutement ça se trouve facilement et c'est beaucoup plus facile d'avoir des devs fullstack (la séparation front/back est une aberration organisationnelle de mon point de vue, créée de toute pièce à cause de la complexité du front, inutile, de ces dernières années).
C'est ma première boîte où on fait des SPA (avec React) et si on veut parler de productivité, j'ai jamais vu pire pour l'instant

Gros projet ça.
 
Y a déjà du GraphQL dedans ?

Impossible de trouver des RH400 d'occase sur des sites sérieux

c'est pas si clair que ça à l'ecrit , je reverrai ma copie, mais là on est dimanche

spour ça que je pars sur du nuxt (la version react , c'est nextjs) : SSR puis progressive enhacement(mais j'ai un biais pour le js ) . Ici il y a des devs PHP (beaucoup ) et une équipe vue qui est en train d'être montée avec pas mal de profils sympa qui arrivent en début d'année.

Le gain, c'est pour les pages qui vont avoir du contenu lié, mais mis à jour séparément ( une fiche d'un passager avec des tableaux de voyages qui peuvent être navigués sans rehcarger toute la page ni gérer à la main les requêtes HTTP).

C'est aussi un vrai gain de perf quand c'est bien fait, avec uniquement les données qui circulent, avec de la gestion de cache locale / partiel, avec des mises à jours optimistes. Mais c'est facile de faire de la merde et encore plus de faire de l'overengineering
edit oublié : des formulaires dynamiques utilisables qui ne passent pas par 17 étapes de validations et retour en arrière
 

oui, je commence juste a  m'y retrouver, et il y a des masses d'endroits sombres que je n'ai pas encore visité
nope

La dernière fois que j'ai vu qqn dessiner un truc comme ça, il lui manquait 80GW pour envoyer une DeLorean dans le futur

PQ

"faites mijoter pendant 3heures"

Ô que j'aime les plats d'hiver

Le site des impôts des entreprises, mais putain quelle purge... ils peuvent pas juste ajouter un bouton "Payer" juste à coté de l'impôt ?
 
Non bien sûr, il faut ouvrir l'avis d'imposition, copier la référence de l'avis, retourner dans le menu, aller dans un autre écran de paiement, insérer son numéro fiscal et coller la référence de l'avis... bien sûr le tout sans la moindre explication, faut deviner ça tout seul.

Oui donc c'est exactement ce que je pensais. Le problème, c'est qu'il est toujours possible de créer une requête qui va faire ramer ton backend, donc le seul moyen d'éviter cela c'est effectivement d'avoir un évaluateur du coût des requêtes et d'interdire certains types de requêtes. Or ça, ça peut être assez vite compliqué à mettre en place et l'évaluateur devrait se mettre régulièrement à jour à partir de métadonnées reçues de la base de données elle-même.

L'idée de GraphQL est pas mal au départ, mais ça, c'est quand même un vrai problème.

Le but, ce n'est pas tant la recherche de la productivité, c'est:
- réduire le nombre de requêtes HTTP. Au vu du site GraphQL, quand c'est bien fait, ça a l'air de marcher pas mal.
- une plus grande flexibilité pour le client puisqu'il n'est pas limité par l'API REST que le serveur publie. Par exemple, les services de l'état pourraient fournir du GraphQL vers leurs bases de données publiques, et on pourrait directement les requêter avec R ou Excel. Pour les statisticiens, ce serait un gain de temps et une flexibilité absolument considérables.

Donc il y a de vrais avantages à cette spec. Mais le problème, c'est qu'en effet, elle ne prévoit rien sur la sécurité des données et sur la protection du serveur contre des attaques DoS (même pas distribuées). Tant qu'il n'y aura pas une couche de sécurité sophistiquée dessus, difficile de s'en servir pour un accès grand public, et même en interne à une administration ou une entreprise, les serveurs sont à la merci d'une requête moisie.

Le second est clairement une question de productivité: les fronteux ont beaucoup moins besoin de changements backend pour monter leurs features (ils font leurs sélections en vertical et en horizontal dans le tas de trucs qui leur est fourni), et qu'ils ont pas besoin de se monter des chaînes d'appels pour les différents niveau de sélection dont ils ont besoin. Ça diminue la friction nécessaire quand ce ne sont pas les mêmes personnes qui sont en charge des deux (ou bien qu'ils sont pas gérés de la même manière), et ça diminue la dépendance du front sur les livraisons back (ils sont quand même dépendent d'avoir des types / queries qui fournissent ce dont ils ont besoin, mais ton type graphql va généralement être beaucoup plus riche de base dans la mesure où le back gagne pas grand chose à le restreindre).

Le 1er, c'est aussi une question de bande passante: non seulement ton graphql peut faire son requêtage en profondeur sans avoir des chaînes de requêtes, mais ne va pas ramener la quantité de bordel que tu aurais avec un endpoint plus classique qui ferait la même chose (vu que tu sais pas top sélectionner horizontalement, donc tu ramènes généralement des tonnes de merde dont tu te fous complètement).

Les services de l'état pourraient aussi bien fournir des accès (programmatiques) HTTP "classiques" vers leurs DBs.

dites, les websockets c'est mort ou c'est encore utilisé ? ils font quoi les gens qui veulent du push maintenant ? http2, ou encore autre chose ?

 
Nous on utilise et ça me semble irremplaçable dans notre cas (il y a beaucoup d’événements en live qui doivent remonter de manière interactive dans l'appli web).

Tu as des flux binaires ? Sinon les server sent events peuvent le remplacer on dirait.