Node.js + Svelte + MongoDB + Tailwind + VSC

Le 01 juin 2024 à 11:47:46 :

Le 01 juin 2024 à 11:36:37 :

Le 01 juin 2024 à 11:32:45 :

Le 01 juin 2024 à 11:22:35 :

Le 01 juin 2024 à 11:19:36 :

> Le 01 juin 2024 à 11:16:31 :

>> Le 01 juin 2024 à 11:14:11 DSFat a écrit :

> > > Le 01 juin 2024 à 11:12:00 :

> > > J'imagine que tu utilises MongoDB qui est bdd non relationnel pour y mettre un orm par dessus pour quelle deviennent relationnelle ?

> >

> > Oui Mongoose

>

> Pourquoi ne pas utiliser une vraie base de données relationnelle avec tous les avantages que cela comporte ? MongoDB ne sert que pour des cas spécifiques. Je sais qu'il y a une mode autour de cela, mais c'est une très mauvaise chose, tu t'en rendra compte au fil du temps que ça n'a aucun sens

Tu parles aux fonds de panier chez les Devs là.

Les mecs tu leur enlève leur joujou ils bégaient.

Ils utilisent MongolDB mais ne comprennent rien aux système distribués. Théorème CAP ? Connais po. Eventual consistency non plus... Jusqu'au jour où : ah merde alors je vois plus mes données pourtant j' ai bien sauvegardé

C'est impossible de perdre des données avec Mongo à moins d'utiliser une version d'il y a 10 ans ou d'être un idiot.

Impossible de perdre des données si t'es sur du mono instance oui.. Et encore si c'est mal configuré tu peux quand même perdre les données. Flush et fsync ça te dit qqchose ?

Bordel ça parle base de données mais ça comprend même pas comment c'est persisté sur disque...

Et toi tu connais ce qu'il se passe niveau OS et hardware aussi à la perfection quand tu utilises une BDD ?

Il y aura toujours des aspects abstraits dans ce qu'on utilise hein, c'est quoi ce délire à prendre les gens de haut ?

Quand on fait du Html et du CSS qui vraiment comprend l'impact sur les perfs et la mémoire, comment le moteur du navigateur voit le squelette du html, etc ?

Oui quand on utilise une bdd savoir quand c'est flushe sur disque c'est la base. C'est pas parce que ta base de dit que c'est persisté que ça l'est réellement hein...

Pareil pour le html et les technos Web

Mais bon je parle à une génération se Devs qui consomme les technos comme du fast food...

Qu'est ce que tu ne comprends pas dans le fait que dès que ta requête est retournée en succès elle est écrite dans le journal sur le disque ?

Le 01 juin 2024 à 11:49:06 :

Le 01 juin 2024 à 11:42:31 :
Du coup c'est marrant ce topic. On assiste à une opposition entre deux types de devs :
- ceux qui ont suivi un tutoriel et sont partis sur MongoDB sans trop de réflexion.
- ceux qui critiquent MongoDB avec des arguments erronés ou alors faux depuis des années parce qu'ils n'ont pas fait l'effort de se remettre à niveau.
Je suis d'accord que Mongo est juste un outil avec ses cas d'usages spécifiques.

Je connais très bien Mongo et les autres NoSQL comme Cassandra etc...

C'est très utiles dans des cas spécifiques

Mais les utiliser comme techno par défaut, surtout pour les juniors c'est de la connerie à l'état pur

Ça fait 5 pages que je répète que c'est overkill pour mes projets

Le 01 juin 2024 à 11:50:48 :

Le 01 juin 2024 à 11:47:46 :

Le 01 juin 2024 à 11:36:37 :

Le 01 juin 2024 à 11:32:45 :

Le 01 juin 2024 à 11:22:35 :

> Le 01 juin 2024 à 11:19:36 :

>> Le 01 juin 2024 à 11:16:31 :

> >> Le 01 juin 2024 à 11:14:11 DSFat a écrit :

> > > > Le 01 juin 2024 à 11:12:00 :

> > > > J'imagine que tu utilises MongoDB qui est bdd non relationnel pour y mettre un orm par dessus pour quelle deviennent relationnelle ?

> > >

> > > Oui Mongoose

> >

> > Pourquoi ne pas utiliser une vraie base de données relationnelle avec tous les avantages que cela comporte ? MongoDB ne sert que pour des cas spécifiques. Je sais qu'il y a une mode autour de cela, mais c'est une très mauvaise chose, tu t'en rendra compte au fil du temps que ça n'a aucun sens

>

> Tu parles aux fonds de panier chez les Devs là.

>

> Les mecs tu leur enlève leur joujou ils bégaient.

>

> Ils utilisent MongolDB mais ne comprennent rien aux système distribués. Théorème CAP ? Connais po. Eventual consistency non plus... Jusqu'au jour où : ah merde alors je vois plus mes données pourtant j' ai bien sauvegardé

C'est impossible de perdre des données avec Mongo à moins d'utiliser une version d'il y a 10 ans ou d'être un idiot.

Impossible de perdre des données si t'es sur du mono instance oui.. Et encore si c'est mal configuré tu peux quand même perdre les données. Flush et fsync ça te dit qqchose ?

Bordel ça parle base de données mais ça comprend même pas comment c'est persisté sur disque...

Et toi tu connais ce qu'il se passe niveau OS et hardware aussi à la perfection quand tu utilises une BDD ?

Il y aura toujours des aspects abstraits dans ce qu'on utilise hein, c'est quoi ce délire à prendre les gens de haut ?

Quand on fait du Html et du CSS qui vraiment comprend l'impact sur les perfs et la mémoire, comment le moteur du navigateur voit le squelette du html, etc ?

Oui quand on utilise une bdd savoir quand c'est flushe sur disque c'est la base. C'est pas parce que ta base de dit que c'est persisté que ça l'est réellement hein...

Pareil pour le html et les technos Web

Mais bon je parle à une génération se Devs qui consomme les technos comme du fast food...

Qu'est ce que tu ne comprends pas dans le fait que dès que ta requête est retournée en succès elle est écrite dans le journal sur le disque ?

Et du coup c'est quoi l'intérêt de Mongo par rapport à un PG ? Parce que bon Mongo c'est pour du non structuré et du distribué à la base..

Depuis que PG supporte du stockage JSON, l'intérêt de se taper un Mongo à part faire le keke ?

Le 01 juin 2024 à 11:52:41 :

Le 01 juin 2024 à 11:49:06 :

Le 01 juin 2024 à 11:42:31 :
Du coup c'est marrant ce topic. On assiste à une opposition entre deux types de devs :
- ceux qui ont suivi un tutoriel et sont partis sur MongoDB sans trop de réflexion.
- ceux qui critiquent MongoDB avec des arguments erronés ou alors faux depuis des années parce qu'ils n'ont pas fait l'effort de se remettre à niveau.
Je suis d'accord que Mongo est juste un outil avec ses cas d'usages spécifiques.

Je connais très bien Mongo et les autres NoSQL comme Cassandra etc...

C'est très utiles dans des cas spécifiques

Mais les utiliser comme techno par défaut, surtout pour les juniors c'est de la connerie à l'état pur

Ça fait 5 pages que je répète que c'est overkill pour mes projets

OK donc tu sais que c'est overkill mais tu restes dessus quand même parce que les kikolool de Devs fluenceurs sur YouTube sont pas foutu de faire un setup simple de PG et tire un Mongo par grosse flemme.

D'autant plus qu'avec les technos container (docker, podman..) t'as ton PG up & running en 5 secs

Les juniors, vous ne devez pas le prendre mal quand on vous dit que la technologie utilisée n'est peut-être pas appropriée. On vous donne juste des pistes de réflexion, le but étant que vous réfléchissiez à pourquoi utiliser telle technologie et pas une autre.

Si vous êtes développeur juste pour le fun, pour pouvoir créer des projets personnels, ça peut aller. Mais si vous souhaitez être développeur pour en faire votre métier, il faut savoir pourquoi utiliser telle technologie et pas une autre. C'est le métier du développeur d'analyser les technologies par rapport aux besoins. En cas d'erreur, cela peut coûter très cher à l'entreprise

Et personnellement, je suis surtout dans l'incompréhension des formateurs qui forment les juniors avec MongoDB. Ce n'est pas ce qui est le plus intelligent ni le plus utilisé comme base de données. Je me demande si ce n'est pas fait exprès afin de se débarrasser de futur devs pour ne pas boucher le métier.

D'autant plus qu'avec les technos container (docker, podman..) t'as ton PG up & running en 5 secs

Tu vas un peu loin, quand tu es junior tu es déjà submergé par les bases, alors docker et podman ...

Le 01 juin 2024 à 11:31:52 Tony178 a écrit :

Abuse pas non plus, MongoDB n'est pas non plus un jouet tout pourri. Ca peut s'avérer être un choix valable selon les cas.

Oui, dans des cas spécifiques, MongoDB est bien. Typiquement pour stocker des fichiers au format JSON ou des données dynamique dont tu ne connais pas la structure

Par contre, quel est son intérêt quand tu veux avoir des données structurées avec des relations ? MongoDB n'est pas fait pour ça, on est obligé d'ajouter la surcouche Mongoose pour avoir un semblant de relationnel alors que le système n'a pas été prévu pour ça.

Si je ne me trompe pas, il n'y a même pas de système de transactions dans MongoDB.

Normalement, données structurées + relations = base de données SQL relationnelle, c'est le choix le plus judicieux.

Pour un junior sur un projet personnel ce n'est pas très grave c'est bien d'y toucher, outre le fait qu'il perd son temps à apprendre une techno qui ne lui servira probablement jamais et ferait mieux de se concentrer sur le SQL.

Par contre, dans un vrai projet de startup ou d'entreprise, là, ça craint

Je sais bien, depuis que j'ai découvert que Postgres permet d'avoir des champs JSON pour stocker des données à la structure variable comme pour le NoSQL je ne jure que par ça. Quelque soit le projet tu finit forcément par avoir des relations donc autant miser sur cette structure mixte.

Après dans le milieu startup t'as plein de CTO qui mise encore sur le NoSQL parce qu'ils sont bloqué sur une ancienne stack genre Ruby+Ror+MangoDB qui a fait tourner beaucoup de projets à une époque.

Le 01 juin 2024 à 11:58:08 :

D'autant plus qu'avec les technos container (docker, podman..) t'as ton PG up & running en 5 secs

Tu vas un peu loin, quand tu es junior tu es déjà submergé par les bases, alors docker et podman ...

Oui je sais, je parles de setup clé en main pour les juniors..

Si les influ voleurs faisaient correctement leur taff, un setup complet a base de Docker Compose avec les technos standards ça prend 5 secs à démarrer mais non voilà les mecs foutent un truc comme Mongo dans la main des juniors...

Le 01 juin 2024 à 11:54:24 :

Le 01 juin 2024 à 11:50:48 :

Le 01 juin 2024 à 11:47:46 :

Le 01 juin 2024 à 11:36:37 :

Le 01 juin 2024 à 11:32:45 :

> Le 01 juin 2024 à 11:22:35 :

>> Le 01 juin 2024 à 11:19:36 :

> >> Le 01 juin 2024 à 11:16:31 :

> > >> Le 01 juin 2024 à 11:14:11 DSFat a écrit :

> > > > > Le 01 juin 2024 à 11:12:00 :

> > > > > J'imagine que tu utilises MongoDB qui est bdd non relationnel pour y mettre un orm par dessus pour quelle deviennent relationnelle ?

> > > >

> > > > Oui Mongoose

> > >

> > > Pourquoi ne pas utiliser une vraie base de données relationnelle avec tous les avantages que cela comporte ? MongoDB ne sert que pour des cas spécifiques. Je sais qu'il y a une mode autour de cela, mais c'est une très mauvaise chose, tu t'en rendra compte au fil du temps que ça n'a aucun sens

> >

> > Tu parles aux fonds de panier chez les Devs là.

> >

> > Les mecs tu leur enlève leur joujou ils bégaient.

> >

> > Ils utilisent MongolDB mais ne comprennent rien aux système distribués. Théorème CAP ? Connais po. Eventual consistency non plus... Jusqu'au jour où : ah merde alors je vois plus mes données pourtant j' ai bien sauvegardé

>

> C'est impossible de perdre des données avec Mongo à moins d'utiliser une version d'il y a 10 ans ou d'être un idiot.

Impossible de perdre des données si t'es sur du mono instance oui.. Et encore si c'est mal configuré tu peux quand même perdre les données. Flush et fsync ça te dit qqchose ?

Bordel ça parle base de données mais ça comprend même pas comment c'est persisté sur disque...

Et toi tu connais ce qu'il se passe niveau OS et hardware aussi à la perfection quand tu utilises une BDD ?

Il y aura toujours des aspects abstraits dans ce qu'on utilise hein, c'est quoi ce délire à prendre les gens de haut ?

Quand on fait du Html et du CSS qui vraiment comprend l'impact sur les perfs et la mémoire, comment le moteur du navigateur voit le squelette du html, etc ?

Oui quand on utilise une bdd savoir quand c'est flushe sur disque c'est la base. C'est pas parce que ta base de dit que c'est persisté que ça l'est réellement hein...

Pareil pour le html et les technos Web

Mais bon je parle à une génération se Devs qui consomme les technos comme du fast food...

Qu'est ce que tu ne comprends pas dans le fait que dès que ta requête est retournée en succès elle est écrite dans le journal sur le disque ?

Et du coup c'est quoi l'intérêt de Mongo par rapport à un PG ? Parce que bon Mongo c'est pour du non structuré et du distribué à la base..

Depuis que PG supporte du stockage JSON, l'intérêt de se taper un Mongo à part faire le keke ?

Si t'es intéressé par le sujet je te conseille cet article : https://jimb-cc.medium.com/postgres-jsonb-meets-mongodb-part-1-the-basics-43d9fc95c40b
Globalement faire des queries sur du json avec Postgres ça peut vite devenir infernal.

A part Mongo, il y a quoi de grave dans nos utilisations sur les frameworks ?
Node.js c'est aussi sans doute overkill pour ce qu'on fait non ?
On pourrait tous rester sur PHP vanilla, html, css, et un peu de JS avec de l'Ajax non ?

Node.js était vu comme un ovni il y a 10 ans, c'est devenu plus populaire que PHP sur les nouveaux projets il me semble, la plupart des frameworks PHP c'est aussi usine à gaz, les cms aussi, les frameworks shop aussi

C'est pour ça qu'on utilise svelte kit et tailwind pour qu'à la fin les compilateurs ne gardent que le nécessaire

Le 01 juin 2024 à 11:59:34 :

Le 01 juin 2024 à 11:31:52 Tony178 a écrit :

Abuse pas non plus, MongoDB n'est pas non plus un jouet tout pourri. Ca peut s'avérer être un choix valable selon les cas.

Oui, dans des cas spécifiques, MongoDB est bien. Typiquement pour stocker des fichiers au format JSON ou des données dynamique dont tu ne connais pas la structure

Par contre, quel est son intérêt quand tu veux avoir des données structurées avec des relations ? MongoDB n'est pas fait pour ça, on est obligé d'ajouter la surcouche Mongoose pour avoir un semblant de relationnel alors que le système n'a pas été prévu pour ça.

Si je ne me trompe pas, il n'y a même pas de système de transactions dans MongoDB.

Normalement, données structurées + relations = base de données SQL relationnelle, c'est le choix le plus judicieux.

Pour un junior sur un projet personnel ce n'est pas très grave c'est bien d'y toucher, outre le fait qu'il perd son temps à apprendre une techno qui ne lui servira probablement jamais et ferait mieux de se concentrer sur le SQL.

Par contre, dans un vrai projet de startup ou d'entreprise, là, ça craint

Je sais bien, depuis que j'ai découvert que Postgres permet d'avoir des champs JSON pour stocker des données à la structure variable comme pour le NoSQL je ne jure que par ça. Quelque soit le projet tu finit forcément par avoir des relations donc autant miser sur cette structure mixte.

Après dans le milieu startup t'as plein de CTO qui mise encore sur le NoSQL parce qu'ils sont bloqué sur une ancienne stack genre Ruby+Ror+MangoDB qui a fait tourner beaucoup de projets à une époque.

Startup, cto déjà rien qu'à ces mots clé je m'en fuis.

Souvent c'est des grosses banques. Choix techniques délirants, souvent pour faire le beau sur son CV avec pleines de technos à la mode.

0 refactoring, dette technique monstrueuse...

Doctolib par ex, les mecs sont restés sur un putain de Monolith géant écrit en... Ruby..encore un choix débile hérité des années 2010 impossible à dégager....

Le 01 juin 2024 à 12:01:23 lepasboomer02 a écrit :

Le 01 juin 2024 à 11:58:08 :

D'autant plus qu'avec les technos container (docker, podman..) t'as ton PG up & running en 5 secs

Tu vas un peu loin, quand tu es junior tu es déjà submergé par les bases, alors docker et podman ...

Oui je sais, je parles de setup clé en main pour les juniors..

Si les influ voleurs faisaient correctement leur taff, un setup complet a base de Docker Compose avec les technos standards ça prend 5 secs à démarrer mais non voilà les mecs foutent un truc comme Mongo dans la main des juniors...

Oui c'est pas faux, je sais pas d'où vient ce délire avec Mongo, ils ont sponso des influ ou quoi

Le 01 juin 2024 à 11:55:49 souil51 a écrit :
Quel enfer le web bordel.
Il faut utiliser 15 outils, 12 frameworks, 3 technos différentes...
Et tout ça pour faire du JavaScript (ou typescript qui est un peu mieux), c'est moche, c'est pas optimisé, c'est peu lisible.
Et en plus tout les 2 ans, c'est une nouvelle technologie qui doit être utilisé, des autres frameworks..
C'est pas si terrible à petites doses mais beaucoup de dev web ne savent en fait pas coder, ils savent juste faire du script sur des framework...

L'enfer c'est pas le nombre d'outils mais

1. le changement constamment des stacks au grés de la hype du moment
2. comme tu dis, le fait que beaucoup ne sont creuse pas dans le même temps le savoir théorique

>

> Impossible de perdre des données si t'es sur du mono instance oui.. Et encore si c'est mal configuré tu peux quand même perdre les données. Flush et fsync ça te dit qqchose ?

>

> Bordel ça parle base de données mais ça comprend même pas comment c'est persisté sur disque...

Et toi tu connais ce qu'il se passe niveau OS et hardware aussi à la perfection quand tu utilises une BDD ?

Il y aura toujours des aspects abstraits dans ce qu'on utilise hein, c'est quoi ce délire à prendre les gens de haut ?

Quand on fait du Html et du CSS qui vraiment comprend l'impact sur les perfs et la mémoire, comment le moteur du navigateur voit le squelette du html, etc ?

Oui quand on utilise une bdd savoir quand c'est flushe sur disque c'est la base. C'est pas parce que ta base de dit que c'est persisté que ça l'est réellement hein...

Pareil pour le html et les technos Web

Mais bon je parle à une génération se Devs qui consomme les technos comme du fast food...

Qu'est ce que tu ne comprends pas dans le fait que dès que ta requête est retournée en succès elle est écrite dans le journal sur le disque ?

Et du coup c'est quoi l'intérêt de Mongo par rapport à un PG ? Parce que bon Mongo c'est pour du non structuré et du distribué à la base..

Depuis que PG supporte du stockage JSON, l'intérêt de se taper un Mongo à part faire le keke ?

Si t'es intéressé par le sujet je te conseille cet article : https://jimb-cc.medium.com/postgres-jsonb-meets-mongodb-part-1-the-basics-43d9fc95c40b
Globalement faire des queries sur du json avec Postgres ça peut vite devenir infernal.

Si ton data modèle est vraiment non structuré effectivement Mongo est un meilleur choix.
Mais en réalité dans 99% des cas réels, ton data modèle est fortement structuré

T'as 2/3 cas à la marge où c'est dynamique donc json.

Donc non, si t'as besoin de faire des requêtes de fou sur du JSON c'est soit ton use case justifie pleinement un Mongo, soit t'as un data modèle pourri à revoir.

J'ai switch sur Bun + Hono + BiomeJS, plus jamais je reviens sur Node + Eslint + Express (ou fastify)

Je fais beaucoup de Rust aussi depuis des années, sah quel plaisir

Dommage que dans mon taff, on soit toujours sûr du PHP pur sans aucun framework, 7 sites sur la même instance d'apache et PHP-FPM, sah quel enfer

Le 01 juin 2024 à 12:03:59 lepasboomer02 a écrit :

Le 01 juin 2024 à 11:59:34 :

Le 01 juin 2024 à 11:31:52 Tony178 a écrit :

Abuse pas non plus, MongoDB n'est pas non plus un jouet tout pourri. Ca peut s'avérer être un choix valable selon les cas.

Oui, dans des cas spécifiques, MongoDB est bien. Typiquement pour stocker des fichiers au format JSON ou des données dynamique dont tu ne connais pas la structure

Par contre, quel est son intérêt quand tu veux avoir des données structurées avec des relations ? MongoDB n'est pas fait pour ça, on est obligé d'ajouter la surcouche Mongoose pour avoir un semblant de relationnel alors que le système n'a pas été prévu pour ça.

Si je ne me trompe pas, il n'y a même pas de système de transactions dans MongoDB.

Normalement, données structurées + relations = base de données SQL relationnelle, c'est le choix le plus judicieux.

Pour un junior sur un projet personnel ce n'est pas très grave c'est bien d'y toucher, outre le fait qu'il perd son temps à apprendre une techno qui ne lui servira probablement jamais et ferait mieux de se concentrer sur le SQL.

Par contre, dans un vrai projet de startup ou d'entreprise, là, ça craint

Je sais bien, depuis que j'ai découvert que Postgres permet d'avoir des champs JSON pour stocker des données à la structure variable comme pour le NoSQL je ne jure que par ça. Quelque soit le projet tu finit forcément par avoir des relations donc autant miser sur cette structure mixte.

Après dans le milieu startup t'as plein de CTO qui mise encore sur le NoSQL parce qu'ils sont bloqué sur une ancienne stack genre Ruby+Ror+MangoDB qui a fait tourner beaucoup de projets à une époque.

Startup, cto déjà rien qu'à ces mots clé je m'en fuis.

Souvent c'est des grosses banques. Choix techniques délirants, souvent pour faire le beau sur son CV avec pleines de technos à la mode.

0 refactoring, dette technique monstrueuse...

Doctolib par ex, les mecs sont restés sur un putain de Monolith géant écrit en... Ruby..encore un choix débile hérité des années 2010 impossible à dégager....

Oui souvent il y a le sacrifice de la propreté des pratriques pour l'elfamoso agilité terrain.
Après pour le choix de ROR je trouve ça limite plus respectable que certaines équipes qui réécrivent tout leur code tous les 2 ans en fonction des tendances

Node.js c'est aussi sans doute overkill pour ce qu'on fait non ?

L’intérêt de node à mon sens c'est surtout pour avoir tout en JS, un seul langage pour le front et le backend. Et profiter du large écosystème de JS qui est autant un avantage qu'un inconvénient.

la plupart des frameworks PHP c'est aussi usine à gaz

Ça dépend de ton projet, un simple site statique n'a pas besoin de framework par exemple.

Le 01 juin 2024 à 12:08:02 HarryPottaire a écrit :
J'ai switch sur Bun + Hono + BiomeJS, plus jamais je reviens sur Node + Eslint + Express (ou fastify)

Je fais beaucoup de Rust aussi depuis des années, sah quel plaisir

Dommage que dans mon taff, on soit toujours sûr du PHP pur sans aucun framework, 7 sites sur la même instance d'apache et PHP-FPM, sah quel enfer

Du vanilla PHP ? courage