|
Auteur | Sujet : [blabla@hosto] Le topic des vieux |
---|
gfive | Reprise du message précédent :
Ça fait chier. --------------- Tous les sud africains sont ségrégationistes, à part Ted. (P. Desproges) |
Publicité | Posté le 22-11-2020 à 06:44:20 |
Profil supprimé | Posté le 22-11-2020 à 08:22:20 Salut pluvieux.
|
el muchacho Comfortably Numb |
|
el muchacho Comfortably Numb |
Message édité par el muchacho le 22-11-2020 à 08:36:59 |
gfive |
--------------- Tous les sud africains sont ségrégationistes, à part Ted. (P. Desproges) |
el muchacho Comfortably Numb | Un truc de ce genre: https://en.wikipedia.org/wiki/3Dconnexion |
ratibus |
|
flo850 moi je |
Le client est authentifié, donc ça limite la casse et on sait où regarder
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 A long terme : migration du monolithe services PHP vers des services plus digestes et plus modernes (pas des microservices non plus )
Message cité 1 fois Message édité par flo850 le 22-11-2020 à 10:39:39 --------------- |
flo850 moi je |
Message édité par flo850 le 22-11-2020 à 10:10:23 --------------- |
Publicité | Posté le 22-11-2020 à 10:28:47 |
masklinn í dag viðrar vel til loftárása |
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. Message cité 1 fois Message édité par masklinn le 22-11-2020 à 10:52:13 --------------- Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody |
flo850 moi je |
Dans un monde idéal je te rejoins 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é. Message cité 1 fois Message édité par flo850 le 22-11-2020 à 11:10:09 --------------- |
masklinn í dag viðrar vel til loftárása |
--------------- Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody |
flo850 moi je | pour moi la DDR4 3200 est a 1600Mhz, donc elle est déjà pas mal overclockée (moyennant les cas) --------------- |
gfive |
--------------- Tous les sud africains sont ségrégationistes, à part Ted. (P. Desproges) |
flo850 moi je |
Sauf erreur de ma part les requêtes qui vont faire peter une base de données sont
Message cité 1 fois Message édité par flo850 le 22-11-2020 à 11:39:26 --------------- |
flo850 moi je |
--------------- |
gfive |
--------------- Tous les sud africains sont ségrégationistes, à part Ted. (P. Desproges) |
masklinn í dag viðrar vel til loftárása |
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.
Message cité 1 fois Message édité par masklinn le 22-11-2020 à 13:58:29 --------------- Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody |
ratibus | 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).
Message cité 2 fois Message édité par ratibus le 22-11-2020 à 14:09:03 |
flo850 moi je | pour le lien, c'est une mine d'information --------------- |
flo850 moi je |
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. 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 Message édité par flo850 le 22-11-2020 à 14:30:17 --------------- |
flo850 moi je | 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
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 ? Message cité 2 fois Message édité par flo850 le 22-11-2020 à 15:04:12 --------------- |
masklinn í dag viðrar vel til loftárása |
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).
Message cité 1 fois Message édité par masklinn le 22-11-2020 à 14:48:53 --------------- Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody |
masklinn í dag viðrar vel til loftárása | rati pr0n: https://www.youtube.com/watch?v=UXnEzwJpbBg --------------- Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody |
nraynaud lol |
--------------- trainoo.com, c'est fini |
flo850 moi je |
--------------- |
ratibus |
|
flo850 moi je |
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
Message cité 1 fois Message édité par flo850 le 22-11-2020 à 16:15:15 --------------- |
Jubijub Parce que je le VD bien |
--------------- Jubi Photos : Flickr - 500px |
el_barbone too old for this shit ... |
--------------- En théorie, la théorie et la pratique sont identiques, en pratique, non. |
flo850 moi je | "faites mijoter pendant 3heures" Ô que j'aime les plats d'hiver --------------- |
el muchacho Comfortably Numb |
L'idée de GraphQL est pas mal au départ, mais ça, c'est quand même un vrai problème.
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. Message cité 1 fois Message édité par el muchacho le 22-11-2020 à 17:52:47 |
masklinn í dag viðrar vel til loftárása |
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).
Message édité par masklinn le 22-11-2020 à 17:24:09 --------------- Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody |
lorill | 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 ? |
Plam Bear Metal |
--------------- Spécialiste du bear metal |
lorill |
|
Publicité | Posté le |
Sujets relatifs | |
---|---|
Plus de sujets relatifs à : [blabla@hosto] Le topic des vieux |