Skip to main content

Building an Optimized Backend Environment

Competitive Programming  and Backend are two really different fields, but I feel that there's a great connection between them. Backend Development is mainly about storing User Data, and building endpoints and queries to efficiently retrieve them. Once you get the hang of it, it becomes fairly easy. Honestly, I don't even feel that there's anything challenging in it unless you have a really big project to build where there are tons of endpoints and jobs. Even that, to be honest, will just require better project structure and you're sorted.

The real challenge for me, though, is deciding the format of the databases. I had learnt a Software Design principle in one my classes, and till date, I think it's the best way to efficiently design any project. Here's the 6-step procedure:

  1. Specify the problem
  2. Specify Data Structures
  3. Define Format of Data Structures
  4. Specify Algorithm
  5. Look for modularity
  6. Repeat above steps
I know it's not perfectly built for Backend Development, but if you're good with analogies, you'll know that the 'problem', is the project idea, 'Data Structures' can be our project's Data Base, 'algorithm' can be how we're going about outputting data for endpoints, and 'modularity' would mean subdividing our code features into different sections.

The last point emphasizes that we should always keep checking all our steps and validate our steps. Although the design principle says that the repetition should be restricted only to the designing phase, I make sure I'm following the steps even while implementation.

Looking for Modularity

Let's look at the second-last point again - Modularity. This point not be as important for some fling side projects as they are for bigger projects with a lot of code and data. The ease of Debugging is inversely related to the Chaos of Code. Once we figure out the different things that a project does, we can subdivide the features into modules. This gives us a rough idea of all the things that we need to do to complete the project. Now, the features can be assigned to people as tasks. The 6th step of repetition can be used, that is, let's say we divided our project into feature A and B. So the 5 steps can again be applied to simplify feature A, and likewise, for B. I love this step because the ease with which you are able to build any project totally depends on this very step of designing.

Algorithm Specification    

This is a fairly obvious point. Although there isn't any big 'algorithm' for every endpoints response, specifying what happens in every step is perhaps the core part of designing.

Data Structures Specification

This is the 2nd point in the 6-step procedure. Specifying the Data Bases. The next step, Specifying the Format of Data Bases is closely linked with this step too. Together, these steps decide your project's real scalability. In today's world, Data plays the most important role in everything. All AI, ML, etc applications that you want to build in your project will need a lot of Data, any website that you build will need you to store User's data, and your content. All this data needs to be stored in such a way that it is efficiently retrieved in the fastest possible time from the Data Base. 

This step, honestly, is the toughest one for me. Sure, you can build a side project in any format you want, but how you store that data will impact the difference in response times when your project starts to scale. Imagine the amount of optimizations that engineers at Google, Facebook and Amazon must have done to deliver such quick response times! And this is the area, where most Backend Developers must strive to improve. 

Backend Developers must know what kind of Data Base would maintain their project after scaling. Usage of Graphs, Trees, LinkedLists is something which I have never done in my projects. Certainly there must be ways & situations to implement these in real-life projects. The question is, how do we decide when to use which data structure? 

There is a lot of theory that could give you some idea about applications of Data Structures, but if you're a good coder, I can say that you don't like memorizing. Referencing the conditions needed for usage of a DS is not as good as being able to visualize the project through that application. 

So now the question is, how do we get to the state where we can decide for ourselves what kind of optimizations to use & when? 
By practicing cases where it can be used and actually implementing it on code. That's where Competitive Programming comes in. CP is something that will definitely teach you how to optimize everything in your project. That is the best way to learn the applications of Data Structures and Algorithms I've found till date. Building an API or a Website is easy, but making it efficient is tougher. That is the challenge you should aim for.


Popular posts from this blog

Namaste JavaScript Quick Notes

Note:  Akshay Saini's Namaste JavaScript is probably the best course for JavaScript developers out there. These are my personal notes that I made while watching the course; they serve more of as an online quick reference for my understanding and revision, and I hope it benefits anyone reading it too! Everything in JS happens inside an Execution Context. Before a JS code is run, memory is allocated and variables are set as undefined   , and functions are set as their exact code in the scope within the Execution Context. The global execution context hosts all the global variables and function definitions. An Execution Context has 2 components: Memory, that stores variables and functions; and Code, that reads and executes the code. Call Stack maintains the order of execution contexts. Since JS is single threaded and asynchronous, at one point of time, only one function is executed which is at the top of the call stack. For each function, an execution context is created before executi

An introduction to APIs

API is an acronym for Application Programming Interface. Let's start with first defining some basic terms: Browser: These are browsers. To visit any website on the internet, you need a browser. Server: Hmm, this is tough. In simple words, server is a computer. Yes, just like the laptop, or PC at your home. The only difference is that it does not have a screen. Of course, there are other differences in technical specifications, but at its core, the server is just, simply, a computer. That's it. So why is it called a server? Because it serves . When you go to a website like , your computer connects to the internet and gets you your search result. But your computer's internet connection has to get that result from somewhere, right? If the google search result is giving you some answers, the answers have to come from somewhere. What is that place? The answer to that some place is: a server. When you click on the search button on google, or hit enter after typing, &q

Review: Nestjs - Finally a scalable way to build APIs

I have been thinking about this for a long time. There HAS to be a defined way to build APIs in a scalable way.  If you have used Node, Express, etc in your side projects, you might have felt that after a point in development, debugging truly becomes a pain. Sure, enterprise-level API codes are great. But a lot of times, these configurations are too much, and probably not even needed in other projects. To be honest, I haven't seen a lot of Open-Source API codes either to make a judgement on how experienced developers build their APIs. Anyway, I came across an amazing framework recently, and I think if you are coding a complex API, this should be your way to go. Nest.js Nest.js is a framework for building efficient, reliable and scalable server-side applications.  You essentially break your APIs into controllers, services, and modules, which allow you to modularize the smallest of functionalities in your endpoints or the API as a whole. Why is modularizing important? As I have talk