Storing & Rendering Blogs: no markdown-parser
Tags: javascript, database, webdev, react
Published: 2022-11-05 16:14:29

I've been trying to put together a blog for myself and a point comes when one needs to start thinking about strategies to store the blogs somewhere. One common strategy you find in a lot of tutorials is using some third-party library that parses markdown to the desired semantic, for eg. [ `react-markdown` ](https://www.npmjs.com/package/react-markdown). Now, speaking of the goods of such a library, it (hopefully) tackles the security concerns that come with letting external HTML render on a site. This is the security concern that leads to *dangerous* function names such as `dangerouslySetInnerHTML`, quoting the [ react docs ](https://reactjs.org/docs/dom-elements.html#dangerouslysetinnerhtml), just " to remind yourself that it’s dangerous " . On a serious note, [XSS attacks](https://en.wikipedia.org/wiki/Cross-site_scripting) can be a major pain in the posterior. Apart from that, such libraries also eliminate the need to implement your own markdown parser.

That being said, I have this little itch to **NOT** use such a library for my blog. 

![I'm not in danger, I am the danger](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/t7in0d3zxli8zkumhjyf.jpg)

Using such a third-party library would mean adding to your dependency tree and also succumbing to making your whole site rely on its maintenance. Also, using it might be very practical for a client project but I am looking forward to learning something here and I think I am pretty skilled already in `npm i <package>` and copying boilerplate from the documentation.

In this article, however, we should just focus on the strategies for implementing text processing in the blog to have basic formatting capabilities and for creating a good enough schema for storing it in a database. If I succeed, you should see this become a 10-part series or more. 🤓

## Preface

Before moving any further, let me clarify that although the text-parsing mainly happens in the frontend, I would also be speaking about how various things are done in a node-express backend. But this isn't meant for people who are completely new to `express` or backend in general. I would expect awareness about REST APIs and how it is implemented in `express` from the readers. Additionally, we will probably also be talking about regular expressions ( Perl-compatible ) in javascript. If you think you don't fit in here, let me point you to some resources to get you ready!

- REST APIs and Express: [docs](https://expressjs.com/), [short video](https://www.youtube.com/watch?v=-MTSQjw5DrM)
- Regular Expressions: [docs](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_Expressions), [short video](https://www.youtube.com/watch?v=sXQxhojSdZM)

## Let's begin

We first need to plan how we store the blogs in a database. Rather than storing completely as a secondary markup language that needs parsing, I would like to store it in a format the database is more familiar with. Assuming that we are using a NoSQL document database like MongoDB, we can start drawing a rough picture of our model as a JSON. The same can also easily be translated into a relational table. However, for simplicity, we stick to JSON.

```
blogModel = {
  author : user
  created at: date
  title: string
  tags: [ strings ]
  image: string
  body: [
    { type:  "head" | "para" | "quote" | "image" | "code" ,
	  value: string   }]
}
```
This roughly represents the schema for a single blog entry in our database. To summarize it: in short, we store the author, creation date, title of the blog entry, an image for the cover, and the body of the article. The focus here is the body of the entry which will be an <u>array of individual sections</u> of the entry. If we are talking about relational representation, this could be thought of as a foreign key to a sections table. This way we will have more flexibility while styling the elements in our frontend as they would already be isolated as headings, images, code blocks, etc. Additionally, we will add styles for text formatting and links using **regular expressions**.

![In Theory, This should work](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/3tz3zefrcnmn2lmbmvm5.png)

Now that we spent our time in the back, let's think about how this would look on the front. Once the blog is uploaded, it should look typically the same as the one you are reading right now. The part we care about is the editor which will be used for sending post requests to our backend. This is the part where we need to process user's text into a form that our backend will understand. For now, this lays down a simple layout for our create-blog page.

The text processing needed for turning whatever user enters into our editor should be implemented in the client with some [regular expressions](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_Expressions) magic. This should be the highlight of this project and while other things are important, this is the part that will decide whether the whole idea works or breaks.

There may be some other smaller concerns like where we plan to store the images for our blog. Here, one option would be to store it right in the database or maybe in the server and the other would be to use a storage service available, for instance, as you might have noticed, sites like [dev.to](https://dev.to) seem to be using either [AWS s3](https://aws.amazon.com/s3/) or [cloudinary](https://cloudinary.com) for storing images. The latter should be a better option but it largely depends on the scale of our application. A personal blog with very few images should not require a pricey service.

With that being said, I kept this one less populated with code and more with the general plan. You can tell me if you like the idea or point out if I am missing some key aspects that might start to cause some trouble once I am deep into the project. Or, you can share any of your ideas of how a better route can be taken for what I'm trying to achieve. 

Hopefully, in the next part, we will get deeper into the implementation. We will make use of regular expressions, express, and CSS/Javascript for styling.