Etude de cas NoSQL
LXCDM : une interface administrable NoSQL avec une base MongoDB
LXCDM reprend une logique proche de Relativement, mais avec une base documentaire MongoDB. C'est un bon terrain de comparaison entre un modele SQL strict et une structure NoSQL plus souple pour des blocs, cartes, sections et contenus editoriaux.
Structure technique
Le backend est construit avec Node.js, Express 5 et Mongoose. La connexion MongoDB passe par mongoose.connect, puis les contenus sont organises en modeles : cards, blocks, banners, sections, page intros, policies et users.
Cette structure NoSQL est pertinente pour des contenus modulaires. Les blocs peuvent evoluer sans imposer la meme rigidite qu'une table SQL classique, tout en gardant des schemas Mongoose assez explicites pour rester maintenable.
Interface et contenus
Cote frontend, le projet partage une logique de kit React avec blocs texte/image et editeur riche Tiptap. L'objectif est de reutiliser les memes briques d'administration au lieu de reinventer chaque ecran.
Le backend expose des routes separees par domaine fonctionnel. Cette organisation rend le projet plus lisible : chaque controleur gere une responsabilite precise, ce qui aide beaucoup quand le projet grossit.
Images WebP et SEO
Les uploads passent par Multer en memoire, puis Sharp convertit les images en WebP avec une qualite cible de 80. Les fichiers generes sont nommes de maniere unique et servis depuis des dossiers publics comme /img/block, /img/cards ou /img/uploads.
Cette logique donne un benefice direct pour le SEO technique : moins de poids image, moins de bande passante, et des pages plus rapides sur mobile. Le format WebP est integre au flux d'upload, pas traite comme une optimisation manuelle apres coup.
Ameliorations SEO
LXCDM integre l'optimisation au moment ou le contenu est cree : les images de blocs et de cards sont redimensionnees et converties en WebP avant d'etre publiees. Cela evite d'accumuler des medias trop lourds dans le temps.
La structure en sections, cards et blocs aide aussi le referencement : chaque contenu peut garder un titre, du texte, une image et un alt. C'est une base propre pour construire des pages indexables sans multiplier les composants sur mesure.
Securite backend
Le backend valide les entrees d'authentification avec Joi, hash les mots de passe avec bcrypt, et emet des JWT expires au bout de trois heures. Le token est envoye en cookie httpOnly, secure et sameSite=None, ce qui evite de l'exposer directement au JavaScript client.
Le projet utilise aussi Helmet, CORS, express-rate-limit et Winston. Ce sont des briques classiques, mais importantes : elles posent des garde-fous sans rendre l'architecture inutilement complexe.
Exemples de code
Ces extraits viennent du depot GitHub du projet. Ils illustrent la difference NoSQL, la conversion WebP automatisee et le choix d'un cookie d'authentification plus protecteur.
Connexion MongoDB avec Mongoose
export async function connectDB() {
try {
await mongoose.connect(process.env.MONGO_URI);
logger.info('Connexion MongoDB reussie.');
} catch (error) {
logger.error(`Erreur de connexion MongoDB : ${error.message}`);
process.exit(1);
}
}Conversion WebP lors de la creation d'un bloc
await sharp(req.file.buffer)
.resize({ width: 1200 })
.webp({ quality: 80 })
.toFile(outputPath);
payload.image = `/img/block/${filename}`;Cookie JWT httpOnly
res.cookie("token", token, {
httpOnly: true,
secure: true,
sameSite: "None",
maxAge: 1000 * 60 * 60 * 3
});Ce que ce projet montre
- Une base MongoDB adaptee aux contenus modulaires et evolutifs.
- Une separation claire entre modeles, controleurs, routes et middlewares.
- Une conversion WebP integree directement aux uploads.
- Une authentification plus protectrice avec bcrypt, JWT court et cookie httpOnly.