Reprise du message précédent :
Oui, no controller custom sont majoritairement là pour réaliser des actions d'écritures.
 
Pour de la lecture ça m'a l'air d'être une approche foireuse

J'ai pas de corp, je suis employé par l'

 
Tu payes chômage / retraite ou tas un statut sans impôts + mega salaire pour le faire de ton coté ?

Il n'y a pas qu'interpol qui a ce fonctionnement ?

 
Les organisations internationales (OCDE...)

 
Fuis pauvre fou

Ouiiiiiiiii, Yann Marguet relance les orties
https://www.youtube.com/watch?v=KWp7usESwvU
 
Son accent lausannois est absolument fantastique.

statut fonctionnaire européen, tu cotises directement pour la retraite a l'Europe qui elle abonde aussi en plus.

Amazon on a beau dire, c'est inégalable le service.
Cet après-midi, je retourne un produit à un point UPS. Et là je vois qu'il est déjà remboursé, quelque chose comme 3h après.

Putain... embauche-moi

ils remboursent en avance car ils savent que dans la plupart des cas ça se passe bien, l'avantage d'avoir beaucoup de POGNON

 
Oui on arrête pas de le dire ... Et de le vérifier les rares fois où un problème se pose.    
 
Ils sont imbattables.

y'a des postes ouverts à Luxembourg, en plus tu peux gagner une partie de salaire en plus comme prime d'expat

Care to elaborate?
 
Je trouvais ça sympa moi le sql over http pour moins dépayser les collègues de l'exploitation accrochés à leurs sgbd comme des moules à leur rocher

 
Après chez Amazon, c'est aussi un choix et une culture d'entreprise... Amazon aura été déficitaire très lourdement pendant des années et ils ont toujours eu cette politique. Évidemment, maintenant qu'ils sont bourrés de pognon, ils s'en foutent encore plus, mais ça date pas d'aujourd'hui.

pas de cache au milieu, obligé de faire le cache coté client ( et si tu regardes le code d'appolo pour voir comment c'est fait, c'est loin d'être trivial )
si tu t"eloignes trop du schéma sous jacent , tu te fais rattraper par la réalité au niveau des performances  
la gestion des droits n'est pas standardisé
la syntaxe des reducer est indigeste
 
 
mais en vrai,  j'aime beaucoup graphql avec react/vue  pour afficher des datatable + hasura sur une base postgresql côté serveur

 
Comparaison : Apple :  
Date de la commande : 17.09
Refus de livraison : 24.09
Remboursement : 06.10
 
Note : refuser la livraison est le moyen le plus rapide de se faire rembourser, il est impossible d'annuler la commande après qu'elle soit passée. J'avais le choix d'accepter la livraison et faire un retour, ou refuser la livraison.
 
Y'a 10 ans on avait un meilleur service chez Nespresso (sur ~30 pays, avec des entrepôts décentralisés), je me gausse
 
Donc oui, le service Amazon déboite

Oui tu as raison, j'ai jamais eu a me plaindre d'Amazon depuis que j'y commande.
Toujours réglo, 99.9% dans les temps, retour sans soucis

Y a plein de challenges avec GraphQL qui sont beaucoup + simples à gérer en REST (sécurité, cache...).
Du coup, à moins d'exposer une API publique ou à beaucoup de clients que tu ne maîtrises pas et avoir un intérêt à leur exposer des endpoints super souple, clairement ça vaut pas le coup selon moi. Donc je trouve les use-case limités.
Ou alors du GraphQL pour une interface d'administration éventuellement.

j'ai fait du graphql pour de l'exposition de data warehouse uniquement en interne, pour du public rating bus à raison j'ai toujours exposé du REST jusqu'à présent
 
Et encore au final l'équipe qui a repris par après a préféré rester sur du simple spring data qui permet en 2-3 lignes de config d'exposer une API REST CRUD sur des tables données, qui en interne est pas deconnant non plus et ils attaquaient ca en Python donc ça les emmerdais de changer leurs habitudes je crois

En fait ils te remboursent dès que le colis est enregistré par UPS, le délai de 3h c’est ta banque qui lagge

Rien que ca...
 
Jamais compris l'intéret de graphql en fait. De toute facon tu donneras pas toute latitude a ton application, et de toute facon les use cases ou ca a l'air de rentrer ressemble plus a Meteor.JS qu'autre chose (a savoir, trop peu de use case utile, et trop de risque que ca parte en couille).
 
Apres je me pose la question, si tu tombes sur un pb de perf, comment tu geres justement, quand je vois la tronche de certaines queries que l'on a qui tappent 1k ligne+ facile, je me pose pas une demi-seconde la question d'un truc qui te donne en réalité pas la main dessus... De facto ca ressemble plus a un truc pour de petit projet que vraiment du lourd avec des contraintes de perfs pas mal fortes...
 
Apres j'ai pas non plus spécialement fouillé, justement je suis resté bloqué sur la partie sécurité, qui a l'époque était globalement vide de bonne pratique a premiere vue...

On peut parler de JSON-RPC sinon

 
On se mets bien je vois  

 
CORBA, vrais savent

RMI wins by KO

On fait ce qu'on peut mon bon monsieur  

Diminuer le couplage et la dépendance du front sur le back, en évitant les patterns d'accès vraiment pessimaux et en limitant la perte de bande passante.

T'as des équipes front qui font des essais principalement en lecture en permanence, qui vont pas nécessairement voire le jour, tu veux pas qu'ils soient en permanence bloqués par le back. Avec GQL, le back peut gérer l'expositions et les permissions de manière relativement grossière (surtout si ton modèle de permission est pas trop fin) et une fois qu'un objet est exposé n'importe qui peut l'utiliser dans le front, et avec un système de recherche global auto-publié une équipe front sans rapport peut le trouver s'ils en ont besoin, et aller l'utiliser sans faire chier personne.

Avec la recherche en profondeur ça évite les access patterns complètement dégénérés genre n+1 ou accéder aux objets un par un, ça facilite aussi le développement du front (moins de soupe de promesses / callbacks, surtout que ça prédate async/await), et t'as des équipes dédiés qui surveillent et peuvent prendre en main une query qui pose problème avec un handler custom.

Si en plus tu branches ça directement dans ton framework d'UI, les fronteux vont pas aller sélectionner le monde, ça va automatiquement sélectionner uniquement ce qui est utilisé, et tout bien rafraichir.

L'optimisation sur la lecture est très visible sur le fait que les mutations sont pas fondamentalement mieux que le RPC classique… mais vont embarquer une query à l'intérieur donc quand tu fais ton appel tu peux direct rafraichir ce qui t'intéresse via la réponse. Pendant ce temps le caching réseau tu t'en fous si tu pars du principe que les données sont super volatiles et que tu vas jamais fetcher 2x la même chose, tu veux surtout limité la quantité par fetch, et pouvoir pointer juste ce que tu veux pour maj ton client.

Avec des trucs plus classiques (que ce soit du RPC "classique" ou du pas-REST), les endpoints ont une réutilisabilité limitée sauf s'ils sont tout petits (ou vraiment énormes), donc soit t'augmentes le couplage (chaque changement de front touche le back) soit t'augmentes énormément ta conso réseau avec des millions de micro-requêtes ou des documents kilométriques qui partent directement à la poubelle. Mais le couplage front/back c'est pas gênant quand ce sont les mêmes gens, ou au moins des gens qui bossent ensemble / pas loin.

Après c'est moins utile si tu sais streamer tes maj en live via des souscriptions et un socket, genre.

C'est plus l'inverse en fait.

Et le cache tu t'en fout un peu dans le sens où le cache local est malin et refresh les données intelligemment

Couplé a un framework réactif c'est transparent pour l'utilisateur

La où ça déboite c'est pour des donnes trop grosses pour tenir dans le cache d'un client , auxquelles tu accède de différentes façons Avec des filtres(un compte bancaire par exemple)

Autre bonus: en général les.donnes sont typées et decouvrables , ce qui te permet avec un peu de plomberie de présenter des choses joliment facilement, notamment quand on parle de dates

Hasura qui se mets par dessus postgresql construit quasi tout par introspection, y compris la majeure partie des agrégations, ou une surveillance des changements très optimisée

"- bon alors gamin, il s'est passé quoi aujourd'hui ?
- aujourd'hui il y avait l'alarme incendie
- ah, et du coup vous avez fait quoi ?
- rien, on n'a pas entendu la sonnerie "
 

J'ai un pote qui vient d'être embauché chez redhat (c'est genre sa 1e semaine, ou 2e), aj il y avait une réunion générale parce qu'ils sont "federal contractors" donc ils vont tomber sous le coup de l'ordre de vaccination et il y en a qui pêtent des cables

Voilà, disons que le cache http tu t'en tapes parce-que tu pars du principe que dans tous les cas il pourra rien faire, par contre t'as un client intelligent et t'as des caches "fragmentaires" à travers toute ton infra back.

Ah ouai c'est bien possible.

Chez nous ils ont pas eu l'info que facebook est réparé (la photo du bas)
https://www.larep.fr/orleans-45000/ [...] _14024557/

Nous on passe en niveau de risque 2/5 la semaine prochaine ! On va pouvoir prendre le petit dej, le dîner et faire la sieste au bureau \o/

Pass sanitaire obligatoire, apparemment la discussion a été assez simple les représentants du personnels y étaient largement favorable. Pour l'instant c'est encore facultatif le retour au bureau donc il est question de virer personne.

 
A première vue j'avais noté la sécurité à implémenter un peu différemment, j'avais pas pensé au cache...mais à l'échelle de ce projet c'est probablement pas un pb de pas être archi efficace.
La souplesse me plait vraiment bien, par contre, et le coté "on fait un truc un peu rigolo et pas juste une bête api REST" m'apporterait un peu de motivation
 
Après j'avais aussi des doutes sur la bonne manière d'implémenter du multilingues avec un truc pareil, je vois a priori rien de très adapté pour juste passer quelque part la langue qu'on veut avec ce que j'ai lu de la doc, c'est un peu gênant...

Npm down
https://status.npmjs.org/incidents/7pqfqvkwvb58

https://curia.europa.eu/juris/docum [...] id=6413406

Note que l’article 5(1) en question s’applique « In the absence of specific contractual provisions »

Ça a le mérite d'être bien plus concis que tout ce que j'ai pu lire sur le sujet merci
 
Tu as un exemple d'un custom handler sous la main peut être que je regarde un peu ?

Nope

J'ai étudié un peu graphql à l'époque pour savoir ce qu'il en ressortait mais au final j'ai conclu que c'était pas trop mon truc et j'en ai jamais eu l'utilité La seule fois où j'ai essayé d'en consommer c'était pour taper dans l'API v4 de github et franchement elle est pas terrible