Forum |  HardWare.fr | News | Articles | PC | Prix | S'identifier | S'inscrire | Aide | Shop Recherche
1805 connectés 

 


Sujet(s) à lire :
    - Who's who@Programmation
 

 Mot :   Pseudo :  
  Aller à la page :
 
 Page :   1  2  3  4  5  ..  23644  23645  23646  ..  23654  23655  23656  23657  23658  23659
Auteur Sujet :

[blabla@prog] Le topic de ceux qui ne répondent pas à Jovalise

n°2368952
gfive
Posté le 22-11-2020 à 06:44:20  profilanswer
 

Reprise du message précédent :

ratibus a écrit :


Le PC que vous avez monté ensemble ?


Ouais.

 

Ça fait chier.


---------------
Tous les sud africains sont ségrégationistes, à part Ted. (P. Desproges)
mood
Publicité
Posté le 22-11-2020 à 06:44:20  profilanswer
 

n°2368953
faston
la lumière fuse
Posté le 22-11-2020 à 08:22:20  profilanswer
 

Salut pluvieux.
Ici on a beau temps.


---------------
Des gestes simples et ponctués, par quelques points presque important ; La précision coordonée d'une île déserte, des plans secrets d'un architecte à la retraite, passionné par son métier, tracer des routes, les emprunter.
n°2368954
el muchach​o
Comfortably Numb
Posté le 22-11-2020 à 08:33:26  profilanswer
 

flo850 a écrit :

c'est givré dehors :cry:
 
Et sinon GraphQL >>>>> Rest


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.

n°2368955
el muchach​o
Comfortably Numb
Posté le 22-11-2020 à 08:35:34  profilanswer
 


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


Message édité par el muchacho le 22-11-2020 à 08:36:59
n°2368956
gfive
Posté le 22-11-2020 à 09:11:50  profilanswer
 


 
:D 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 :o)


---------------
Tous les sud africains sont ségrégationistes, à part Ted. (P. Desproges)
n°2368957
el muchach​o
Comfortably Numb
Posté le 22-11-2020 à 09:14:08  profilanswer
 
n°2368960
ratibus
Posté le 22-11-2020 à 09:46:43  profilanswer
 

flo850 a écrit :

c'est givré dehors :cry:
 
Et sinon GraphQL >>>>> Rest


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 :d : 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 :D

n°2368961
flo850
moi je
Posté le 22-11-2020 à 10:00:23  profilanswer
 

el muchacho a écrit :


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.


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

 
ratibus a écrit :


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 :d : 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 :D

 


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

Message cité 1 fois
Message édité par flo850 le 22-11-2020 à 10:39:39

---------------

n°2368962
flo850
moi je
Posté le 22-11-2020 à 10:01:51  profilanswer
 

nraynaud a écrit :


c'est vraiment important de virer le SQL de l'équation ?

 

perso du SQL où on pourrait mettre des projections et des sélections dans des variables, ça me paraitrait bien ?


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)

nraynaud a écrit :

 

‘Tain je viens de tenter de résoudre un système 3x3 à la main, si vous me cherchez, je suis en train d’hyperventiler en PLS sur le parquet [:pingouino]

 


Spoiler :

et maintenant on va aller googler la bonne réponse, je debugge pas ça ! [:petrus75]


 
nraynaud a écrit :

https://i.imgur.com/57hSryl.png

 

tiens, je me suis vautré, comme d'hab.

 


Sauvage et gg


Message édité par flo850 le 22-11-2020 à 10:10:23

---------------

n°2368963
gfive
Posté le 22-11-2020 à 10:28:47  profilanswer
 

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 :o


---------------
Tous les sud africains sont ségrégationistes, à part Ted. (P. Desproges)
mood
Publicité
Posté le 22-11-2020 à 10:28:47  profilanswer
 

n°2368964
masklinn
í dag viðrar vel til loftárása
Posté le 22-11-2020 à 10:49:54  profilanswer
 

flo850 a écrit :

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


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.

Message cité 1 fois
Message édité par masklinn le 22-11-2020 à 10:52:13

---------------
I've never understood the compulsion to use Web technologies minus the Web's security and deployment models. It seems a bit like throwing the orange away and eating the peel. — @ justinschuh‬
n°2368965
flo850
moi je
Posté le 22-11-2020 à 11:07:09  profilanswer
 

masklinn a écrit :


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.

Message cité 1 fois
Message édité par flo850 le 22-11-2020 à 11:10:09

---------------

n°2368966
gfive
Posté le 22-11-2020 à 11:08:47  profilanswer
 

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é!


---------------
Tous les sud africains sont ségrégationistes, à part Ted. (P. Desproges)
n°2368967
masklinn
í dag viðrar vel til loftárása
Posté le 22-11-2020 à 11:10:22  profilanswer
 

flo850 a écrit :

Dans un monde idéal je te rejoins


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.

flo850 a écrit :

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


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.


---------------
I've never understood the compulsion to use Web technologies minus the Web's security and deployment models. It seems a bit like throwing the orange away and eating the peel. — @ justinschuh‬
n°2368968
flo850
moi je
Posté le 22-11-2020 à 11:15:03  profilanswer
 

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


---------------

n°2368969
gfive
Posté le 22-11-2020 à 11:21:45  profilanswer
 

flo850 a écrit :

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


 
ah ok :o 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 ?


---------------
Tous les sud africains sont ségrégationistes, à part Ted. (P. Desproges)
n°2368970
flo850
moi je
Posté le 22-11-2020 à 11:28:49  profilanswer
 

masklinn a écrit :


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.


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)

masklinn a écrit :


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.

 

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

Message cité 1 fois
Message édité par flo850 le 22-11-2020 à 11:39:26

---------------

n°2368971
flo850
moi je
Posté le 22-11-2020 à 11:29:44  profilanswer
 

gfive a écrit :


 
ah ok :o 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 ?


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


---------------

n°2368972
gfive
Posté le 22-11-2020 à 11:36:43  profilanswer
 

flo850 a écrit :


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


Non tiens.


---------------
Tous les sud africains sont ségrégationistes, à part Ted. (P. Desproges)
n°2368973
masklinn
í dag viðrar vel til loftárása
Posté le 22-11-2020 à 13:55:24  profilanswer
 

flo850 a écrit :

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

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 :D

 

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

flo850 a écrit :

Les requêtes qui ont beaucoup de résultats, et le navigateur va se suicider probablement assez vite


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

flo850 a écrit :

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


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

Message cité 1 fois
Message édité par masklinn le 22-11-2020 à 13:58:29

---------------
I've never understood the compulsion to use Web technologies minus the Web's security and deployment models. It seems a bit like throwing the orange away and eating the peel. — @ justinschuh‬
n°2368974
ratibus
Posté le 22-11-2020 à 14:03:57  profilanswer
 

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 :D
 
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 :o

n°2368975
ratibus
Posté le 22-11-2020 à 14:05:25  profilanswer
 

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).

Message cité 2 fois
Message édité par ratibus le 22-11-2020 à 14:09:03
n°2368976
flo850
moi je
Posté le 22-11-2020 à 14:10:45  profilanswer
 

:jap: 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.


---------------

n°2368977
flo850
moi je
Posté le 22-11-2020 à 14:19:16  profilanswer
 

ratibus a écrit :

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).

 

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

 


Message édité par flo850 le 22-11-2020 à 14:30:17

---------------

n°2368978
flo850
moi je
Posté le 22-11-2020 à 14:29:55  profilanswer
 

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 ?

Message cité 2 fois
Message édité par flo850 le 22-11-2020 à 15:04:12

---------------

n°2368979
masklinn
í dag viðrar vel til loftárása
Posté le 22-11-2020 à 14:46:47  profilanswer
 

flo850 a écrit :

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 .


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.

flo850 a écrit :

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.


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 :D 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).

flo850 a écrit :

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 ?


No comprendo la questiono

flo850 a écrit :

edit la base de code en question ( sans le dossier vendor bien sûr)


Totals grouped by language (dominant language first):
php:         523 236 (68.00%)
javascript:    245 945 (31.96%) // ca me semble bizarre, c'est probablement des truc de build qui restent)
python:         215 (0.03%)
sh:              67 (0.01%)
xml:             36 (0.00%)
ruby:             5 (0.00%)



Tu utilises pas tokei [:sadnoir]

Message cité 1 fois
Message édité par masklinn le 22-11-2020 à 14:48:53

---------------
I've never understood the compulsion to use Web technologies minus the Web's security and deployment models. It seems a bit like throwing the orange away and eating the peel. — @ justinschuh‬
n°2368980
masklinn
í dag viðrar vel til loftárása
Posté le 22-11-2020 à 14:51:05  profilanswer
 

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


---------------
I've never understood the compulsion to use Web technologies minus the Web's security and deployment models. It seems a bit like throwing the orange away and eating the peel. — @ justinschuh‬
n°2368981
nraynaud
lol
Posté le 22-11-2020 à 14:57:09  profilanswer
 


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


---------------
trainoo.com, c'est fini
n°2368982
flo850
moi je
Posté le 22-11-2020 à 14:59:59  profilanswer
 

masklinn a écrit :


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.


:jap:

masklinn a écrit :


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 :D 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).


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

masklinn a écrit :


No comprendo la questiono


 

masklinn a écrit :


Tu utilises pas tokei [:sadnoir]


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

-------------------------------------------------------------------------------
 Language            Files        Lines         Code     Comments       Blanks
-------------------------------------------------------------------------------
 BASH                    1           42           18           21            3
 Batch                   1           32            7           19            6
 CoffeeScript           12         3990         3115           39          836
 CSS                   488       694390       572865        17673       103852
 Go                      1          284          255           10           19
 HTML                  137        25549        16658         6957         1934
 JavaScript            838       346393       248854        46580        50959
 JSON                   36         4211         4211            0            0
 LESS                  261        20225        16560         1441         2224
 Makefile                1            9            4            2            3
 Markdown               53         6550         6550            0            0
 PHP                  3792       768122       545521       134316        88285
 Python                  5          288          215           26           47
 Ruby                    1           24            5           13            6
 Sass                   27         2519         2401           69           49
 Shell                   1           69           49            1           19
 SQL                    35        13511        11043          827         1641
 Plain Text             25         3212         3212            0            0
 XML                     1           37           37            0            0
 YAML                    6         1201         1198            0            3
-------------------------------------------------------------------------------
 Total                5722      1890658      1432778       207994       249886
-------------------------------------------------------------------------------


---------------

n°2368983
ratibus
Posté le 22-11-2020 à 15:19:29  profilanswer
 

flo850 a écrit :

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 compris non plus ce que tu attendais de nous :o
 
Sachant que s'il n'y avait que moi, on ne ferait pas de SPA hein :D 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 :D

flo850 a écrit :


:jap:
 
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  

-------------------------------------------------------------------------------
 Language            Files        Lines         Code     Comments       Blanks
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------



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

n°2368984
Dion
Acceuil
Posté le 22-11-2020 à 15:27:18  profilanswer
 

Impossible de trouver des RH400 d'occase sur des sites sérieux :fou: [:natas]


---------------
Elmoricq petite bite - Les enfants de vapeur c'est  comme les crevettes, tout est bon sauf la tête !
n°2368985
flo850
moi je
Posté le 22-11-2020 à 15:44:28  profilanswer
 

ratibus a écrit :


Pas compris non plus ce que tu attendais de nous :o

 

Sachant que s'il n'y avait que moi, on ne ferait pas de SPA hein :D 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 :D


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

 

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 :D ) . 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
 

ratibus a écrit :


Gros projet ça.

 

Y a déjà du GraphQL dedans ?


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

Message cité 1 fois
Message édité par flo850 le 22-11-2020 à 16:15:15

---------------

n°2368986
Jubijub
Parce que je le VD bien
Posté le 22-11-2020 à 16:12:38  profilanswer
 

nraynaud a écrit :

https://img3.super-h.fr/images/snap [...] 1d3.md.jpg

 

‘Tain je viens de tenter de résoudre un système 3x3 à la main, si vous me cherchez, je suis en train d’hyperventiler en PLS sur le parquet [:pingouino]

 


Spoiler :

et maintenant on va aller googler la bonne réponse, je debugge pas ça ! [:petrus75]



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


---------------
Jubi Photos : Flickr - 500px
n°2368987
el_barbone
too old for this shit ...
Posté le 22-11-2020 à 16:36:04  profilanswer
 

Jubijub a écrit :


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


---------------
En théorie, la théorie et la pratique sont identiques, en pratique, non.
n°2368988
flo850
moi je
Posté le 22-11-2020 à 16:37:02  profilanswer
 

"faites mijoter pendant 3heures"

 

Ô que j'aime les plats d'hiver


---------------

n°2368989
el muchach​o
Comfortably Numb
Posté le 22-11-2020 à 16:38:01  profilanswer
 

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. [:marc]

n°2368990
el muchach​o
Comfortably Numb
Posté le 22-11-2020 à 17:05:37  profilanswer
 

masklinn a écrit :


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 :D

 

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


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.

ratibus a écrit :

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).


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.

Message cité 1 fois
Message édité par el muchacho le 22-11-2020 à 17:52:47
n°2368991
masklinn
í dag viðrar vel til loftárása
Posté le 22-11-2020 à 17:21:07  profilanswer
 

el muchacho a écrit :

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.


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).

el muchacho a écrit :

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.


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


Message édité par masklinn le 22-11-2020 à 17:24:09

---------------
I've never understood the compulsion to use Web technologies minus the Web's security and deployment models. It seems a bit like throwing the orange away and eating the peel. — @ justinschuh‬
n°2368992
lorill
Posté le 22-11-2020 à 17:41:13  profilanswer
 

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 ?

n°2368993
Plam
:o
Posté le 22-11-2020 à 17:52:14  profilanswer
 

lorill a écrit :

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).


---------------
Ossifié, comme fusionné dans son cockpit
n°2368994
lorill
Posté le 22-11-2020 à 17:56:00  profilanswer
 

Plam a écrit :


 
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.

mood
Publicité
Posté le   profilanswer
 

 Page :   1  2  3  4  5  ..  23644  23645  23646  ..  23654  23655  23656  23657  23658  23659

Aller à :
Ajouter une réponse
 

Sujets relatifs
Plus de sujets relatifs à : [blabla@prog] Le topic de ceux qui ne répondent pas à Jovalise


Copyright © 1997-2018 Hardware.fr SARL (Signaler un contenu illicite) / Groupe LDLC / Shop HFR