Design & Développement web - Le topic des canards qui mangent des cookies

[Charmide]

Y'a pas mal de tes questions qui ont la même réponse je pense Kamikaze: on s'était mit à faire des SPA/clients lourds partout (beaucoup de JS, plein de logique côté navigateur, etc), principalement pour optimiser l'expérience utilisateur et faire des trucs très intéractifs, React et sa grosse popularité ont à peu près stabiliser et évangéliser ça après pas mal de remous. Mais maintenant on est dans l'étape d'après: "ok ça serait peut-être bien de conserver toutes ces possibilités offertes par les SPA mais en ayant les gains de perf pour ce qui pourrait être plus statique ou généré côté serveur, comme ce qu'on faisait avant".

D'où:
1) Pas mal de JS côté serveur, puisque maintenant on s'attend à ce que ton framework de rendu de SPA qui générait la page dynamiquement côté navigateur soit également capable d'en générer/cacher une version plus ou moins finie côté serveur en réponse à une requête, et prenne la main ensuite côté navigateur. Donc c'est transparent, t'écris le même code qu'avant pour des SPA mais t'as divers surcouches qui permette de façon transparentes de générer une v0 de la page côté serveur pour que le temps de rendu initial soit bas (le gros problème historique des SPA qui t'affichait rien avant 5s de temps de chargement de 3 tonnes de JS), mais en même temps une fois cette v0 chargée et affichée, le framework reprend la main pour avoir des trucs dynamiques côté navigateur
2) Cette approche de génération de pages statique côté serveur, au build time. Gatsby a été le premier à ouvrir vraiment ce concept, me semble qu'ils ont commencé sur l'e-commerce (qui a besoin d'avoir des pages bien rendues pour que Google les indexe et leur envoie des clients). Tu veux un truc très intéractif avec des composants React dans une page où 80% du contenu est statique, Gatsby te permet de faire ça facilement de façon unifiée, avec peut-être des plages de pages entièrement statiques ou d'autres entièrement dynamiques et résolues côté navigateurs. D'ailleurs ça me fait penser vu ton post, les âfres de Gatsby (en perte de vitesse relative) c'était les pipelines de CI de 4 ou 5h où des grosses boîtes d'e-commerce générait les pages de 150 000 paires de chaussures x 5 tailles x 4 couleur et autres joyeusetés Sauf qu'à la fin, d'un point de vue client, ça donnait des trucs très proches en termes de perf du bon vieux web ultra statique, ton navigateur n'avait pas à appeler un serveur pour demander les couleurs disponibles avant de rendre la moitié de la page, mais avec quand même la possibilité pour les devs pour faire de bonnes UX bien intéractives.

En regardant côté Jamstack t'auras des infos sur la philosophie de ces trucs là.

... Mais bon le web c'est chiant à décrire parce que t'as des vagues et des modes, en général motivées par une bonne raison/un bon cas d'usage, mais qui n'est pas universelle, et à chaque grosse vague t'as des gens qui restent dans le paradigme d'avant. Du coup je pense que c'est un peu plus fragmenté que les autres écosystèmes même si j'oublie que c'est celui que je connais le mieux. Y'en a plein qui sont pas dans le train dont je parle et qui sont restés sur ruby on rails ou django, à bon escient. Je sais pas comment tu peux faire pour pas être largué si tu t'en pas tapé les 12 ans d'histoire précédentes.

Si tu veux faire joujou je conseille SvelteKit (par-dessus Svelte, tentative de framework fullstack tout en un). C'est hipster mais pas trop et assez en pointe.
Edith: Astro dans un autre registre c'est assez représentatif également d'où on en est, archi intéressante.

- - - Mise à jour - - -

...

Le côté hacker/dev solo/pragmatisme/optimisation de la vitesse d'implem' et d'itération sur ton produit parce que c'est ce qui compte c'est vraiment le quintessentiel du web je trouve, et ce qui me plaît en général. J'ai même poussé le truc encore plus loin et arrêté de faire du dev pour me concentrer sur les aspects utilisateurs/busines, c'est pour dire

[Awake]

Merci les autres canards d'avoir été un peu plus diplomates que moi.

Je suis en train de monter un projet avec NestJS en back, c'est ultra bien... je me suis vraiment tiré une balle dans le pied au bazooka à faire mes propres frameworks JS front/back ces dernières années

[Anonyme20240202]

Ma faute, ma faute, faut pas que je poste après minuit, c'tait pas très fin comme post de ma part

[Captain_Cowkill]

Merci pour cette discussion en tout cas, c'était hyper enrichissant pour un débutant comme moi

[Awake]

Ma faute, ma faute, faut pas que je poste après minuit, c'tait pas très fin comme post de ma part

Pas de soucis, je n'aurais pas du partir au quart de tour.

Discutons de nos opinions respectives sur les IA pour se calmer

[Charmide]

Y'a eu l'annonce de Google hier sur sa riposte à ChatGPT et le générateur de Seinfeld IA qui s'est fait ban de Twitch pour blague transophobe si vous voulez relancer l'autre thread

[Orhin]

Du coup je serais curieux de voir la tech stack des canards qui font du web, genre au pif quand je cherche webpack sur internet, je vois plusieurs projets qui prétendent faire 10x mieux

Webpack ça fait pas vraiment partie de la "stack", c'est juste un outil de build/packaging.
C'est indépendant du framework et des librairies que t'utilises.
Et oui y'a mieux maintenant, mais ça couvre pas forcément tous les cas fonctionnels.
Et y'a bien sur une grosse inertie comme pour tout ce qui est tooling dans tous les domaines de dev en général.

Aujourd'hui mon client me demande de communiquer avec une API pour laquelle je n'ai absolument aucune documentation.

Je viens de me rendre compte que c'est du SOAP.

Comme envie de me petit suicider.

Ouch, bon courage.

[tenshu]

Je viens de me rendre compte que c'est du SOAP.

Moi je vais devoir bosser avec des microservices qui dialoguent en gRPC. Ça me rappelle beaucoup trop soap pour être une bonne idée.

[Awake]

Vous avez une base de documents NoSQL à recommander ? Il y a CouchDB qui me fait de l'oeil, mais je crois que MongoDB est plus populaire, sachant que c'est pour avoir une compétence qui se vend bien.

[tenshu]

Moi j'ai surtout utilisé Redis.

[Awake]

Redis est un peu limité pour ce que je veux faire, il faudrait au minimum du map/reduce.

Je crois qu'en partant sur le plus populaire, la question elle est vite répondue :

[Etheon]

En NoSQL clairement Mongo domine.

J'avais bien aimé utiliser Firebase à l'époque également, mais je ne sais pas si ça répond à tes besoins (ni à la contrainte d'où c'est stocké, vu que Firebase, c'est Google)

[raaaahman]

J'utilise pas mal de Firebase en ce moment. Clairement ça permet d'avoir rapidement des fonctionnalités en place, info-gérées par Google (à priori robuste donc), mais ça force à apprendre tout un paradigme propriétaire pas forcément portable hors des services d'Alphabet Inc. (encore que peut-être que les autres BaaS s'en inspirent, je ne les ai pas testés). Ca me parait adapté à l'ajout de micro-services sur une application existante, après le SDK je le trouve trop rudimentaire pour me lancer dans un projet conséquent avec.

[Dross]

Y'a Cosmo DB aussi dans ce genre de trucs.

De mémoire Cassandra permet aussi le type JSON et de l'utiliser un peu comme un document db.

Honnêtement, je pense que si t'en prends un, et que tu comprends les paradigmes derrière, ça sera bon pour tous. J'ai migré du Azure Table vers du Cassandra, c'était du 1:1 ou presque. La difficulté restait au même endroit (modèle d'objet et dé-normalisation) et la techno derrière.. bah c'est juste une implémentation plutôt qu'une autre.

[gros_bidule]

Tout dépend de ce que tu veux faire en NoSQL. Si tu veux juste stocker du JSON, les bases SQL comme Postres s'y sont mises Si tu veux exploiter des capacités de recherche dans des documents, une vraie base NoSQL sera plus indiquée.
Si tu veux rendre ton cv sexy, alors je plussoie MongoDB, qui est quand même assez répandu. À partir de là, si un jour tu dois bosser avec un cloud provider, alors c'est comme ce que dit Dross, la transition vers ses outils proprio ne sera pas très compliquée. L'intérêt, c'est de comprendre les intérêts (et les contraintes) d'une base NoSQL, qui vont bien plus loin que juste stocker du JSON. Le map-reduce ce n'est pas évident pour tout le monde de s'y mettre, par ex.

[Awake]

J'ai déjà pas mal d'expérience en Cassandra (et la version proprio AWS, Keyspace), je dirais pas que c'est la même chose que MongoDB tout de même, sauf à regarder de loin. Cassandra est vraiment fait pour gérer des I/O extrêmes, du coup y'a pas mal de restrictions (et Keyspace c'est encore pire ). En tout cas la première impression avec Mongo c'est que c'est beaucoup plus souple.

[Dross]

Ah oui c'est pas équivalent, c'est juste que dépendant de ton cas d'usage t'a des trucs "qui ressemblent" ailleurs.

Faudrait que je me replonge dans MongoDB, j'avais touché de loin y'a quelques années ça m'avait laissé une bonne impression.

[tenshu]

Au boulot on réfléchit a faire du CQRS pour le prochain projet qu'on va lancer vu qu'on aurait besoin de faire pas mal de traitements asynchrones et qu'on aura pas ou peu de front

Du coup ça le fait penser que je ne vous ai pas partagé cette conférence d'un estimé ancien collègue sur le sujet.
Les exemples de code sont en php mais on s'en fout il ne fait que les survoler donc même si vous fait du typescript ou du java ou n'importe quoi d'autre ça vous sera utile.



L'event sourcing est juste mentionné à la fin si c'est ça qui vous intéresse il faudra compléter ailleurs.

[Dross]

Le CQRS et l'EventSourcing c'est vraiment top, on s'y est mis il y a 5 ans, c'est vraiment propre même si ça amène un niveau de complexité assez important.

[Charmide]

Moi je vais devoir bosser avec des microservices qui dialoguent en gRPC. Ça me rappelle beaucoup trop soap pour être une bonne idée.

Ca avait l'air sympa gRPC, c'est dans ma liste de trucs à tester un jour depuis des lustres.
En soit l'idée est pas naze, mais bon être adopté principalement dans des grands groupes et pour des applications ~enterprise~ ça te tue n'importe quelle idée

- - - Mise à jour - - -

J'ai déjà pas mal d'expérience en Cassandra (et la version proprio AWS, Keyspace), je dirais pas que c'est la même chose que MongoDB tout de même, sauf à regarder de loin. Cassandra est vraiment fait pour gérer des I/O extrêmes, du coup y'a pas mal de restrictions (et Keyspace c'est encore pire ). En tout cas la première impression avec Mongo c'est que c'est beaucoup plus souple.

Mongo c'est un bon choix par défaut, mais j'ai l'impression que y'a plus grand monde qui choisit par défaut "tant que c'est NoSQL" ces temps-ci.
Si c'est pour optimiser la vitesse de dev et itérer vite sans écrire 32 migrations, je pense qu'un truc 100% hosté ça marche mieux dans l'esprit, sans parler de firebase & co, dynamodb ça doit être celle que j'ai le plus utilisé ces dernières années.
Si c'est pour faire de l'analyse de données et brasser des gros volumes y'a un paquet d'outillage clé-en-main qui en général se débrouille mieux pour être mis par dessus du SQL.

[Awake]

J'ai pas encore attaquer la persistance sur ce projet donc avec plaisir pour discuter des choix techniques.

En gros je vais faire de l'analyse de texte sur les messages du forum, extraire tout un tas de conneries comme les smileys les plus utilisés pour chaque utilisateur (et d'autres trucs plus techniques...). Je vais présenter ça dans une petite interface react, avec un backend en nestjs. Mon plan, comme la base de données sera en lecture seule après l'import initial, c'est de parser et préparer toutes les data à l'avance, et de simplement faire des requêtes comme "top des utilisateurs pour tel smiley". Comme les données seront relativement facilement structurées, je me suis dit que le NoSQL serait une bonne solution.

Je ne souhaite pas partir sur une solution proprio/cloud en revanche, je veux tester le déploiement via Docker sur un petit serveur contenu (je pense même partir sur du bare metal pour economiser).

Je suis ouvert à toute solution technique du moment que c'est un peu sexy sur un CV

[Charmide]

Ca roule, du coup ouais dis comme ça Mongo ça m'a l'air pas mal comme choix neutre effectivement.

Tu me fais penser à ElasticSearch aussi. C'est jamais utilisé comme DB principal mais de fait ça a les mêmes fonctions et le même scope qu'une DB NoSQL, et c'est plutôt bankable pour un CV, j'ai l'impression que toutes les boîtes peu importe leur stack ou archi ont quelque chose quelque part indexé dans un elastic, au moins pour sa fonction primaire d'être bon en recherche textuelle. Mais c'est très flexible. C'est assez bon pour faire des graphs, des leaderboards et du ranking et les requêtes correspondantes aussi, tu peux tester les requêtes dans Kibana avant de refaire ton propre dashboard ou de construire un truc qui les précalculent.

[GrandFather]

Lol une de mes plus belle histoire c'est quand j'ai découvert soap, on me parle de "gSoap", je me dis "ah Google Soap" (pas du tout), ça doit être un truc bien du coup!

Et puis j'ai découvert l'enfer hahaha, pire daube que j'ai jamais vu

Si tu raisonnes en terme d'architecture ça a été pourtant une révolution. Alors certes c'est de la grosse artillerie, mais faut aussi voir que ça a plus de vingt ans, et qu'à l'époque ça a servi, via le web, à faire communiquer ensemble et rendre interopérables des systèmes qui n'avaient pas - mais alors pas du tout - l'habitude de communiquer ensemble jusque-là comme des mainframes, des serveurs J2EE, etc. Le choix de XML comme format de communication permettait de s'affranchir des différences d'encodage, de endianness, etc. entre ces systèmes. Il y a plein d'autres standards qui tournent autour des Web services SOAP, pour le chiffrement, l'EDI...

A notre époque où les architectures matérielles et logicielles ont tendance à s'uniformiser, le besoin est moins présent et ne reste que la lourdeur... Il y a évidemment bien mieux actuellement pour du développement Web.

[Anonyme20240202]

Dans l'idée ce que tu dis parait raisonnable bien sûr. Mais perso quand j'ai jeté les yeux dessus j'ai simplement pété un câble (bon j'ai p'têt le sang chaud faut que je me calme) du fait de la qualité du code, lisibilité de la lib, la doc, le fait que faut payer, etc. etc.

L'argument du choix d'XML je suis pas très convaincu, je vois pas en quoi c'est efficace en terme de théorie de l'information et en terme de lisibilité humaine. J'pige pas pourquoi c'est via HTTP non plus.

Pour moi si tu fais un format (que ce soit de communication ou de stockage, etc.), faut qu'il soit optimal du point de vue machine, et si tu veux le lire tu implémentes une interface qui le traduit.

M'enfin j'ai jamais regardé trop Soap en détail, au final on avait une Archi legacy qui tournait avec Soap, constamment buggée par ailleurs. Pour le nouveau projet j'ai utilisé autre chose (protobuf pour certaines communications et un format binaire propriétaire pour d'autres) sur socket TCP/UDP directement et ça tournait comme un roulement à bille.

D'ailleurs ces crevards refusaient de payer pour gsoap, du coup on utilisait une version obsolète (The gSOAP 2.7.x and 2.8.x releases are distributed under: GPL). Donc s'pas totalement la faute de gsoap cette impression négative. Mais bon quand je vois la gueule du site de gsoap, sans vouloir faire de cliché, j'ai vraiment l'impression de retrouver un truc comme NMAP/NPCAP, un one-man project qui a trouvé sa niche auprès d'entreprises qui pigent rien à l'IT. Et un mec qui s'accroche à ses thunes comme un gripsou alors que y'a un milliard d'alternatives opens source bien meilleures, voire une implem interne vu la faible complexité du problème.

[gros_bidule]

Dans l'idée ce que tu dis parait raisonnable bien sûr. Mais perso quand j'ai jeté les yeux dessus j'ai simplement pété un câble (bon j'ai p'têt le sang chaud faut que je me calme) du fait de la qualité du code, lisibilité de la lib, la doc, le fait que faut payer, etc. etc.

L'argument du choix d'XML je suis pas très convaincu, je vois pas en quoi c'est efficace en terme de théorie de l'information et en terme de lisibilité humaine. J'pige pas pourquoi c'est via HTTP non plus.

Pour moi si tu fais un format (que ce soit de communication ou de stockage, etc.), faut qu'il soit optimal du point de vue machine, et si tu veux le lire tu implémentes une interface qui le traduit.

M'enfin j'ai jamais regardé trop Soap en détail, au final on avait une Archi legacy qui tournait avec Soap, constamment buggée par ailleurs. Pour le nouveau projet j'ai utilisé autre chose (protobuf pour certaines communications et un format binaire propriétaire pour d'autres) sur socket TCP/UDP directement et ça tournait comme un roulement à bille.

D'ailleurs ces crevards refusaient de payer pour gsoap, du coup on utilisait une version obsolète (The gSOAP 2.7.x and 2.8.x releases are distributed under: GPL). Donc s'pas totalement la faute de gsoap cette impression négative. Mais bon quand je vois la gueule du site de gsoap, sans vouloir faire de cliché, j'ai vraiment l'impression de retrouver un truc comme NMAP/NPCAP, un one-man project qui a trouvé sa niche auprès d'entreprises qui pigent rien à l'IT. Et un mec qui s'accroche à ses thunes comme un gripsou alors que y'a un milliard d'alternatives opens source bien meilleures, voire une implem interne vu la faible complexité du problème.

SOAP c'était quand même à une époque où l'on n'avait pas JSON, et surtout on misait encore sur des formats proprio et peu lisibles, dont les outils de lecture étaient peu nombreux, et souvent prorio/fermés/payants. Aujourd'hui tu as des formats ouverts partout et trois milliards d'outils ouverts pour les lire, mais ça c'est finalement récent.
A l'époque, le XML c'était un peu la révolution dans plein de domaines. XML c'est ouvert, ça permet de développer des connecteurs très facilement, bien plus qu'en faisant du Corba par ex (j'ai pleuré du sang pour interfacer Lotus Domino avec des CRMs, ça passait par Corba).

On souhaitait aussi faire plus de XML dans le web, avec XHTML. Fort heureusement, la mode est passée, mais on est passé à "ça" de recoder le HTML en XML .

Idem dans la bureautique : MS Office est passé de ses formats binaires tout buggés que les outils tiers n'ont jamais bien maitrisé, à XML (les fichiers docx etc, c'est un zip avec du XML et des fichiers mutimedia). Le binaire, c'est compliqué.

Si l'on préfère toujours HTTP, et que nous sommes passés à JSON ? C'est bien pour leur simplicité. Le JSON, tu le lis avec n'importe quoi, ça fonctionne bien (donc peu de bugs), tu as plein de super outils (et surtout, tu les as déjà : dans ton navigateur, dans IJ, etc), et tout le monde l'utilise. Et c'est plus lisible que XML. Le HTTP c'est pareil, c'est très simple à utiliser ET à sécuriser. Comme quoi, les devs n'aiment pas se compliquer la vie, et c'est bien normal.

Les formats binaires sont certes plus efficaces en temps de traitement informatique, mais il y a des raisons pour qu'ils n'aient pas remplacé les formats basés sur le texte... J'ai l'impression que tu te focalises sur l'efficacité des programmes, là où d'autres misent sur la simplicité et l'accessibilité, et donc la performance de l'humain, quitte à perdre un peu en perfs machine. Et cette perte de perfs, souvent, on s'en fiche. A quoi bon passer sur un nouveau format, devoir installer des outils pour le debugger, produire des bugs, tout ça pour gagner 10% de perfs qui ne nous serviront à rien ?
Il y a des cas de figure où le binaire est clairement nécessaire, mais pas partout.

[GrandFather]

L'argument du choix d'XML je suis pas très convaincu, je vois pas en quoi c'est efficace en terme de théorie de l'information et en terme de lisibilité humaine. J'pige pas pourquoi c'est via HTTP non plus.
Pour moi si tu fais un format (que ce soit de communication ou de stockage, etc.), faut qu'il soit optimal du point de vue machine, et si tu veux le lire tu implémentes une interface qui le traduit.

Comme je l'ai expliqué, XML est conçu justement pour être lisible par toutes les plateformes, quelle que soit celle qui en est à l'origine, sans nécessiter de conversion préalable. Un gros atout pour de l'interopérabilité. Et HTTP, ben, c'est le protocole du Web (SOAP supporte aussi SMTP, mais c'est anecdotique). Et XML n'a pas que des qualités, il est notamment verbeux (mais étant un format textuel il se compresse bien), mais pour servir de lingua franca entre systèmes il a fait ses preuves. Pas pour rien qu'on le retrouve dans les échanges interbancaires, par exemple.

On peut penser ce qu'on veut de SOAP et XML, mais on ne peut pas dénier aux mecs du W3C qui ont pondu des milliers de pages de standard d'y avoir un peu réfléchi.

[Anonyme20240202]

Ouaip ouaip, plutôt d'accord. Mais je pense que y'a des virages dans l'histoire où on s'est tiré dans le pied du fait de ces choix.

Typiquement regarder une vidéo sur internet, à la base, et sûrement encore beaucoup aujourd'hui c'est du http (over tcp), ce qui est bien évidemment mauvais, c'est pas du tout adapté au transport de contenu video/audio. Pour ça que Google a débarqué avec QUIC/HTTP3 relativement récemment et me semble que les premiers browser à supporter ça c'est genre 2018~

Y'a certes une certaine flexibilité et simplicité à mettre du .json (ou du .xml dieu m'en garde ) et http partout, mais parfois c'est pas le bon choix quoi. Genre historiquement je pense que y'a d'autres exemples du genre où l'on s'accomode d'un standard qui n'est pas approprié.

Objectivement (un alien qui regarde l'avancée technologique humaine depuis sa soucoupe) c'est une anomalie que QUIC soit arrivé aussi tard

[gros_bidule]

En laboratoire, c'est certain, on révolutionnerait le web (tout, en fait). Mais il faut rester compatible avec l'existant, et ce dernier a hélas une force d'inertie incroyable
Donc oui, on se traine aussi des technos pas optimales qu'on aimerait bien remplacer par des trucs 10 fois mieux. TCP et UDP par ex...

[raaaahman]

Je suis ouvert à toute solution technique du moment que c'est un peu sexy sur un CV

Tiens, 15 autres options que tu n'as pas envisagées:

[Anonyme20240202]

l'existant