Node.js + Svelte + MongoDB + Tailwind + VSC

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 dur de savoir tout maîtriser je suis sur un projet ou je dois faire la partie mobile en kotlin et Swift , le web en vue et le serveur en node mongo, ça me demande deja assez de travail , pas le temps de me former à la partie infra

Le 01 juin 2024 à 11:26:00 CuteDoggo a écrit :

Le 01 juin 2024 à 11:03:08 :

Le 01 juin 2024 à 11:01:43 CuteDoggo a écrit :

Le 01 juin 2024 à 10:57:21 :

Le 01 juin 2024 à 10:54:07 :

> Le 01 juin 2024 à 10:49:14 :

>

> # Pourquoi node et non Svelte Kit ?

> # Tu as déjà switch ton projet sur la dernière version de svelte avec les runes ?

> # Pourquoi mongodb et pas firestore ou supabase ?

> # Tu déploies tes apps sur quel service ?

Non bien svelte kit pardon, c'est toujours la confusion entre svelte et svelteKit, c'est pareil pour moi, alors que Svelte c'est juste un compileur (vers html,css,js) et une sorte de langage pardon

Je fais des petits projets, je reste sur Mongo depuis 10 ans, je ne suis pas à la page sur ça, mais je pense pas que ce soit essentiel

Sur des projets ce genre de BaaS (backend as a service) simplifient pas mal de chose, que ce soit en dev ou en prod. Moins de prise de tête pour l'admin du serveur.

En parlant de BaaS , t'en penses quoi de Supabase ?

Faudrait que je me renseigne sur supabase, ça remplace tout ? BDD et Back ? Tu utilises que des apis du coup ?
J'ai vu que ça gère bien l'auth aussi

Pour l'avoir utilisé pour un projet perso, tu fais ta base SQL tu crées tes tables , si elles sont dans le schéma public , elles sont exposés automatiquement grâce au middleware PostGrest qui te génère des routes pour chaque table / fonction
Oui ca gère l'auth, le storage aussi

Exactement.
Leur dashboard est sympa aussi, j'ai bien le fait de pouvoir tout gérer facilement avec une belle GUI sans devoir se connecter avec un client local.
Pour le storage supabase est est cher pour les gros fichiers donc à voir au cas par cas.

Le 01 juin 2024 à 11:28:41 CuteDoggo a écrit :

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 dur de savoir tout maîtriser je suis sur un projet ou je dois faire la partie mobile en kotlin et Swift , le web en vue et le serveur en node mongo, ça me demande deja assez de travail , pas le temps de me former à la partie infra

Te prends pas la tête, il y aura toujours des puristes pour critiquer ton niveau. C'est le lot des fullstacks qui ne peuvent pas être au four et au moulin

Le 01 juin 2024 à 11:27:14 LaCafTombe20 a écrit :

Le 01 juin 2024 à 11:26:00 CuteDoggo a écrit :

Le 01 juin 2024 à 11:03:08 :

Le 01 juin 2024 à 11:01:43 https://www.jeuxvideo.com/profil/cutedoggo?mode=infos a écrit :

Le 01 juin 2024 à 10:57:21 :

> Le 01 juin 2024 à 10:54:07 :

>

> > Le 01 juin 2024 à 10:49:14 :

>

> >

>

> > # Pourquoi node et non Svelte Kit ?

>

> > # Tu as déjà switch ton projet sur la dernière version de svelte avec les runes ?

>

> > # Pourquoi mongodb et pas firestore ou supabase ?

>

> > # Tu déploies tes apps sur quel service ?

>

> Non bien svelte kit pardon, c'est toujours la confusion entre svelte et svelteKit, c'est pareil pour moi, alors que Svelte c'est juste un compileur (vers html,css,js) et une sorte de langage pardon

>

> Je fais des petits projets, je reste sur Mongo depuis 10 ans, je ne suis pas à la page sur ça, mais je pense pas que ce soit essentiel

Sur des projets ce genre de BaaS (backend as a service) simplifient pas mal de chose, que ce soit en dev ou en prod. Moins de prise de tête pour l'admin du serveur.

En parlant de BaaS , t'en penses quoi de Supabase ?

Faudrait que je me renseigne sur supabase, ça remplace tout ? BDD et Back ? Tu utilises que des apis du coup ?
J'ai vu que ça gère bien l'auth aussi

Pour l'avoir utilisé pour un projet perso, tu fais ta base SQL tu crées tes tables , si elles sont dans le schéma public , elles sont exposés automatiquement grâce au middleware PostGrest qui te génère des routes pour chaque table / fonction
Oui ca gère l'auth, le storage aussi

Très nice, tu fais juste tes script custom de ton côté et tu laisse supabase gérer les trucs chiant en somme

C'est ça, tu te prends pas la tête pour la gestion des données, des users/auth et de la mise en prod de ta bdd

Les mecs qui viennent faire les malins ici parce qu'on ne maitrise pas les outils à 100% , c'est quoi le projet ?

On cherche des outils pour être productif et avoir une logique cohérente de dév. On est pas là à créer des sites complexes avec des millions d'utilisateurs chaque seconde à ce que je sache

D'ailleurs c'est bien pour ça qu'il faut des équipes dédiézs à partir d'un certains scale, on a rien inventé, on se partage juste des tuyaux, on ne fait pas les malins, faut arrêter de frimer un moment, on est pas des junior à frimer en pensant tout connaitre alors que pas du tout

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

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

Le 01 juin 2024 à 11:31:52 :

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

Tu te trompes. Les transactions ACID compliant sont implémentées depuis bien longtemps dans Mongo.

perso => React car je fais aussi du react native

sinon tailwindcss j'en suis fan après j'ai jamais utilisé les autres

et si on parle productivité j'ajouterai l'extension Github Copilot dans la stack avec VSC

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

Il y a un système de journaling activé par defaut. Du coup tout est déjà sur le disque même si c'est pas encore écrit dans WiredTiger.

Voilà la doc pour ta culture : https://www.mongodb.com/docs/manual/core/journaling/

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 ?

Le 01 juin 2024 à 11:34:09 Barak39 a écrit :

Le 01 juin 2024 à 11:31:52 :

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

Tu te trompes. Les transactions ACID compliant sont implémentées depuis bien longtemps dans Mongo.

Très bonne chose alors, mais ça reste une base de données qui n'est pas faite pour le relationnel. Quoi qu'il en soit, ce n'est pas grave pour un junior de jouer avec et de faire des projets. Il faut juste essayer de comprendre pourquoi MongoDB existe et en quoi c'est différent de SQL, cela viendra plus tard.

Le 01 juin 2024 à 11:37:50 :
Mongodb pour un petit site alors

perso les seuls fois où j'ai vu du mongdb c'était pour accompagner des petites features au sein de plus gros projets qui utilisait toujours PostgreSQL ou MySQL au final

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

MongoDB n'est pas relationnelle c'est le propre de MongoDB enfaite

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.

Perso je jouais avec MeteorJS pour ceux qui se souviennent, et c'était vraiment pensé pour tourner autour de mongodb de base et depuis je suis resté sur ça, et j'ai pas la prétention de connaitre plus que ce que j'en fais avec, je me doute que c'est surement trop pour ce que j'en fais

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

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