Reprise du message précédent :

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

En parlant de GraphQL.
 
J'ai jamais compris comment tu sécurises quoi que ce soit... J'ai eu beau regardé je sais pas combien de tuto, j'ai fini par abandonner l'idée a cause de ca, t'a des champs en BDD que tu veux pas exposer, certains champs que tu veux restreindre, et d'autres que tu peux vouloir transformer suivant le user avant le renvoi...
 
Tout ces cas là, jamais vu une réponse claire

C'est généralement websocket.

Le "server push" HTTP2 sert pas à ça, et est plus ou moins abandonné. AFAIK le SSE continue à être peu populaire (la limite de connections continue à lui péter les genoux, même si c'est probablement moins gênant si tu utilises aussi des service workers).

chez plamCorps c'est du jsonRPC qui passe sur les websockets, et les messages sont limités à 100Mo.
 

Bah ça va dépendre du besoin de de l'implem que tu utilises en dessous. Généralement t'as un concept de "resolver" qui fait la correspondance entre le graphql (à chaque étage) et le truc qui est derrière (que ce soit des valeurs statiques, une DB, des fonctions de calcul, …), donc tu peux filtrer horizontalement (y compris en fonction du rôle) ou transformer à ce niveau là. Rien ne t'impose de juste exposer toute ta DB en brut.

https://hasura.io/docs/1.0/graphql/ [...] rules.html
C'est built in dans le serveur graphql que j'utilise

Tu peux gérer des permissions d'accès en lecture/écriture par rôle, idéalement récupérés depuis un JWT

Voilà c'est typique de la spécificité de notre use case…

edit : d'ailleurs la PR va être mergé d'ici la release de novembre ?

je pense que oui, elle est validée et prête, mais je sais pas comment marche le train de release.

C'est ce qu'on utilise chez nous, on n'a pas assez de support des trucs plus modernes en backend, et franchement ça ne nous apporterait rien.

Il y a quoi de "plus moderne" que les websockets? La proposition de google pour avoir des sockets bruts?

un truc en javahaskellC#gorust ?

Je pensais aux server sent events qu'a mentionnés lorill plus haut.

C'est plus ancien que les websockets.

Je te garantie qu'il se passe pas un jour sans que t'utilises des WS sans le savoir. Le push et les WS c'est deux choses différentes, tu peux faire du push avec des WS, mais c'est pas fait (uniquement pour ça).  
 
Ce que tu veux c'est les SSE (Server Side Events), sauf erreur de ma part le HTTP2 push permet de pousser des assets de manière préemptive, mais pas des données.
 

Tu peux passer un jwt pour protéger le endpoint.

Ah ok je sais pourquoi je pensais que c'était le contraire.

Parce-que c'est pas arrivé loin de l'autre et tout le monde s'est direct rué sur les websockets avec 2-3 voix derrière qui étaient genre "le SSE c'est cool aussi"

Y'a que toi qui reconnaît mon génie

Merci mes bons

Si vous pouviez éviter d'exposer mes idées novatrices en matière d'UI avant que j'aie terminé ma période d'essai chez skeyecorp, ça serait cool merci

Hey nray, ta chaise c'est une Markus ou une JÄRVFJÄLLET ? tu en es content ?

Ouh là à l'époque je faisais du cuda dans MATLAB moi

Non c'est en lisant les articles de stackoverflow sur les différentes façons de push, genre, en février 2020, que je suis arrivé à cette conclusion

Du coup indirectement ça doit être pour la raison que tu exposes en fait...

Au final après avoir relu un peu de doc SSE c'est assez niche non ? Faut avoir envie de se cogner un protocole de plus alors que websocket couvre simplement plus de use case ?

Moi ma chaise c'est une JÄRJÅRBĪNKS, j'en suis très content  

Markus, j’aurai préféré tout en fillet, la le siège est un coussin. Sinon ça va.

Pour l'instant je ne veux rien, j'essaie vaguement de rattraper mes dix ans de retard en js et assimilé.

Le cas d'usage potentiel que je vois c'est pour streamer des données binaires (genre un IRM en cours).

Je suis pas encore convaincu qu'un browser permet tout ce que fait l'appli desktop sur laquelle je vais bosser, mais j'aimerais bien en sortir car je sens que swing devient de plus en plus obsolète. Du coup je regarde bout par bout, et j'étais surpris de voir que js+canvas, ça marche vite et bien.

Les deux sont arrivés à maturité en même temps, et il y a eu un polyfill qui est arrivé à point nommé côté socket (socket.io) alors que les sse étaient un peu nus
Les browser qui supportaient l'un supportaient aussi l'autre mais les socket étaient un peu plus simple a synchroniser (j'envoie un message j'attends la réponse) alors que pour les sse tu envoies les message en get/post et tu écoute les sse en //

J'ai utilisé des sse a un moment pour contourner des proxy caractériels qui me bouffaient des socket

Ouais, mais SSE est infiniment plus simple et n'a besoin de rien de spécial pour le déploiement, c'est juste une connection HTTP qui reste ouverte sur laquelle tu continues à écrire des trucs, t'as pas besoin d'upgrade, de protocoles brico, etc…

C'est d'ailleurs là qu'est un majeur problème de SSE: comme c'est une connection HTTP normale, si t'es en HTTP/1.1 ça bouffe dans le quota de "connections HTTP par domaine" (6-8 par défaut dans les navigateurs modernes), donc tu te retrouves vite complètement niqué quand tu fais du SSE dans chaque tab et que quelqu'un ouvre plusieurs tabs sur ton site / application. Il y a d'ailleurs un gros callout à ce sujet sur MDN: https://developer.mozilla.org/en-US [...] ventSource

OK merci
La mousse de l'autre a l'air d'avoir été pas mal upgradé et vue que je ne peux pas avoir la chaise que j'espérais

Dis moi Hépha, ça fait au moins 2 jours que je te vois connecté non stop à Beat Saber, t'as laissé ton casque allumé ou quoi ? Je t'ai même envoyé un message sans réponse  

Putain va falloir qu'on te lise l'explication de needy maintenant

Son gros sabre me manque, que veux tu

Bah c'est une grosse session qu'est-ce que tu veux...
 
En vrai j'arrive, je me connecte demain dans la journée...

woké

Pour cyberpunk

merci much

ça n'a que 2 jours , sauf erreur de ma part
 
tu auras un carte graphique avant la sortie ?

 
j'ai jamais su faire un faisceau
je savais les dessiner et expliquer aux usines comment se servir de l'outil pour sortir leurs feuilles de coupe, BoM, etc...  
 
si tu veux je te fais un truc joli sous Google Drawings

J'ai fait le choix d'attendre et de dépiler ma ludothèque plutôt que de no lifer dès la sortie.
 
Mais d'ici la date de sortie j'espère avoir un écran (TBD, à force de lire les tests je vais faire une connerie), un GPU bas de gamme (3070), de la RAM meilleure (3600 CL16), un nouveau air cooling (mon ventilo CM Hyper212 compatible n'a pas l'attache qui va bien pour la mobo), une nouvelle chaise(please v2 ou IKEA) et une nouvelle tv (je me repose des questions sur l'OLED, j'ai peur du marquage).
 
Pas emballé par les standing desk, les retours de mask sur le jarvis bamboo m'ont refroidi, jarvis fume sur le prix du hardwood, 700 balles pour de l'ikea électrique c'est fondamentalement cher, les autres marques sont soit bofbof, soit ne livrent pas de kit complet en France (uplift je pense à toi   )

Le marquage pour l'OLED, c'est un non problème aujourd'hui pour une utilisation normale. Du coup sauf si tu affiches BFMTV 24h/24 pendant des jours avec le bandeau d'information, tu devrais pas avoir de soucis.

Oui cela semble beaucoup plus rare qu'avant mais pas inexistant, et avec une prise en charge merdique via les garanties (ou pire en dehors de la période)
Je voudrais un plan B et un plan C quoi

Enfin AJAX ça existe depuis combien d'années ?
 
Avant d'ajouter une énième techno dans un monolithe de cette taille faut se poser les bonnes questions car ça va pas migrer en 2 secondes et ça va faire une techno de + à connaître pour maîtriser le projet
 
Je recommande cette conf pour des sujets de design d'API qui s'inscrivent dans le temps : https://afup.org/talks/3241-6play-api-v2-final-1-doc
C'est la team d'anciennement M6 web (en charge de 6play), qui s'est détachée de M6 pour s'appeler Bedrock désormais. Et c'est notamment leur plateforme qui est utilisée pour Salto.
 
Je suis convaincu qu'il ne faut pas laisser une trop grande liberté de requêtage métier aux devs fronts (vu qu'au final on parle de cette distinction dev/front), c'est une brèche énorme qui s'ouvre, sous couvert de "ouais mais c'est plus pratique pour moi".

Justement, les SSE c'est plutot un protocole en moins par rapport à WS : c'est du pur HTTP.Pareil, j'ai appris leur existence très récemment (par l'API Stream de Firebase) et c'est surprenant à quel point c'est inconnu par rapport à WS.

Je présume qu’il fait référence au protocole logique (text/event-stream) que tu dois généralement bricoler à la main, alors que pour WS habituellement t’envoies / tu reçois tes messages et tout le framing est géré pour toi.