All solutions are contextual. What I say and question may be weird because I don't the context (ex: are you building a blog engine, is it a CMS, is it for enterprise, is it hosted etc).
1) why mongo db? It is ok to learn it. Unless there is a specific use case for it, it looks like traditional DBs are a good fit for the one you are describing.
2) real-time conversion will be (relatively) expensive. it is better to store the converted html.
3) most compute / conversion should happen at backend. Backend will always be more powerful than the frontend compute engines (browsers, mobiles). You will also avoid idiosyncrasies of these front-end compute engines.
1) Why not MongoDB? Document based databases are an excellent choice for a document based system. I would argue that unless you have a specific need for an SQL-style relational database, it should be avoided.
2) It shouldn't be expensive. Markdown is not a complex language to parse or process. If the DB is remote, it's most likely getting the document will take longer than parsing. Heck, even if it's on the local disk parsing should be faster than loading it. (Markdown libraries may of course vary here)
3) Storing Markdown doesn't imply the front-end needs to process. The front-end can still get HTML. The middle-ware can do the transformation required by the client. Better still, it can translate differently for each client.
Fully agree on point 1. Ideal use case for a document store, especially one with a flexible schema such as mongoDB. If you start to add new data items into your documents, no problem and no headaches having to edit the database. The data is either there or isn't.
Hi ! I'am really intersted by having an exemple where a middle-ware can do the transformation required by the client on the server side !
// GET article by id
app.get('/article/:id', function(req, res) {
Article.findById(req.params.id, function(err, DBdocumentById){
if (err) {
console.log(err.message);
res.redirect('/');
return;
} else {
// Output HTML from DBdocument markdow encoded
// Markdow to html parser
let DBdocumentById_body_md2html = markdown.toHTML(DBdocumentById.body);
res.render('article.pug', {
// Pass DBdocumentById
this_DBdocumentById_title: DBdocumentById.title,
this_DBdocumentById_author: DBdocumentById.author,
this_DBdocumentById_body: DBdocumentById_body_md2html,
this_DBdocumentById_id: DBdocumentById.id
});
}
});
});
`
As you can see in this code, the MD to HTML is directly done into the .get() method, how to use/write a funky custom middleware in the way to keep the .get() method as clean as possible ?
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
All solutions are contextual. What I say and question may be weird because I don't the context (ex: are you building a blog engine, is it a CMS, is it for enterprise, is it hosted etc).
1) why mongo db? It is ok to learn it. Unless there is a specific use case for it, it looks like traditional DBs are a good fit for the one you are describing.
2) real-time conversion will be (relatively) expensive. it is better to store the converted html.
3) most compute / conversion should happen at backend. Backend will always be more powerful than the frontend compute engines (browsers, mobiles). You will also avoid idiosyncrasies of these front-end compute engines.
1) Why not MongoDB? Document based databases are an excellent choice for a document based system. I would argue that unless you have a specific need for an SQL-style relational database, it should be avoided.
2) It shouldn't be expensive. Markdown is not a complex language to parse or process. If the DB is remote, it's most likely getting the document will take longer than parsing. Heck, even if it's on the local disk parsing should be faster than loading it. (Markdown libraries may of course vary here)
3) Storing Markdown doesn't imply the front-end needs to process. The front-end can still get HTML. The middle-ware can do the transformation required by the client. Better still, it can translate differently for each client.
Fully agree on point 1. Ideal use case for a document store, especially one with a flexible schema such as mongoDB. If you start to add new data items into your documents, no problem and no headaches having to edit the database. The data is either there or isn't.
Hi ! I'am really intersted by having an exemple where a middle-ware can do the transformation required by the client on the server side !
`
As you can see in this code, the MD to HTML is directly done into the .get() method, how to use/write a funky custom middleware in the way to keep the .get() method as clean as possible ?