The Story of a Backend — The Database Decisions
Hello and welcome to the second chapter of this amazing journey through a backend.
In this story saga, I would try to cover the creation of the backend and will link a few useful links to see how to host it and show off your amazing work to the world. This will be more of the programming concepts blog and if you want to know how to start with setting up a backend, please read the first part here.
For the sake of this post, I will assume creating a blog application’s backend.
So for our application let’s say we want the application to allow users to make post anonymously(this adjustment is for my convenience to cover as much concepts as possible in a concise way). Let’s list down the features we want in the app
what we want from backend:
→ it should be able to receive posts and store it in a database(we will use sql database, just to give an idea of a stack not that popularly shown).
→ it should allow user to register themselves (because I just realized this is kind of the most basic thing every web app does and would be good to give a demo of handling passwords etc).
→ it should be able to fetch posts from the database and send it to the frontend(using a REST API call. We will throw around a lot of JSON here).
→ should be able to login the user(We will also send a token from our sided so that the user can be authenticated without having to login again and again. Just like in real life😀).
As promised, I will show you a very modular backend considering the developer’s ease as well. So let’s go through the directory structure:
With the aim of modularity, we create a directory for the database, routes and config.
Now you can see how every aspect of backend is separated in different files and folders which makes the code heavily maintainable and easy to make modifications to.
Okay so these are the four very basic tasks we want from our backend. Let’s talk about the tables we will use to store our information. As of now, we only need two tables. Why? because all we want to do is store users and posts. Now because we have a users table we can know who posted the post also but I still want the posts to be anonymous so I don’t ask for email, just a funky username is enough (that ideally should be unique and there are very easy ways to achieve that so for our application I am assuming all usernames are unique. Basics are more important at this point).
So, the following will be the two table schemas(remember we are linking backend to some SQL based database and they have a fixed schema).
Consider the above two very basic table we will use. Now for safety purposes, we will use hashing to store a hash of the password and check the hash of the user password instead of storing the passwords as plain text.
The ‘models’ folder contains information about schema of the table, for example, for user table, the model folder will contain a file users.js or users.ts (you can call the file ironman<.js or .ts> if you want but naming it users makes more sense to me but feel free to be creative with it as long as it makes sense to you). Following is the sample of what the users.ts file will contain for our backend:
I hope that makes sense. The file exports an interface named user which you will understand in about one minute does what (attempt at creating suspense !).
Similarly, we will make another file entry in model for blogs (I’d name it blogs.ts but again feel free to name it whatever makes sense to you). Now at this point I can put another code snippet of what I did but to intensify the suspense, I would leave it for you to make(hint: refer the schema to determine what all things need to go in it). In case of any questions, feel free to contact me and I will do my best to clarify doubts.
We are working on only two tables and so we only keep these two models in the directory.
Now that we have our models, let’s get to the real deal and start building up out database dir. The database directory contains an index file(it’s like the entry point), the database.ts file(does the basic activities for database setup like initialize the database, make sure the tables specified are present and update the metadata all that), the utils.ts (connect to database and query the database tasks are handled by this file’s code), and the tables directory which holds the functions used to do the CRUD(C create, R read, U update, D delete. just wanted to introduce you to this term too) operations on the table.
For example for our blog application, following are the contents of index, database, utils.ts files respectively:
As discussed, we store our connection credentials in a separate cnfig file. The overall point to do so is to have the flexibility to be able to connect to a different database as well if for some reason you want to switch. As I said, modularity++.
I will discuss in a future post, in details about the databases. And hopefully that post will come soon too 😬.
Just an FYI/DIY , the config file looks like this…..
Okay, now let’s talk about making the tables. The database.ts calls the ensureTable method of the tables to ensure the existence of tables in our database.
A sample table file would be like below:
The index.ts is just from where everything is thrown out of to the outside world( to the initialization methods I mean).
p.s. ignore the squigly lines, the code snippets are written as and when needed, as not at the liberty to show any deployed code, just samples🙂.
This may again be getting too long of an article, and I really don’t want to put too much in one post.. So, see you on the next post, where I will discuss about the 🤔.. let’s see what … Once that post is done, the link will be here, no farther, here.
Link to an interesting link to SQL and NOSQL databases discussion.
Until later then!!.. ✌