Let me ask you a question, Do you want to become a modern “web-developer” ? If yes, this is going to be the ultimate guide for you to just exactly do that. Now I am going to throw in some terminologies here but stick around, because we together are gonna win over that fear. So this blog will walk you through a road map from being an absolute beginner to a (caution : fancy terms ahead 😅) Full-Stack developer who knows how to build large scale applications based on Microservices.
If you are curious that for whom this blog is, the answer is anyone who is an Absolute Beginner and above. So lets dive in, shall we ?
Well regardless of if you are a beginner or an absolute expert, this is a very interesting question to think about. And to be very honest a very hard one to answer too. I don’t believe I am the best person to claim to have the most compelling answer to this but my version of answer to this question will be because “Web-Development is the best”. And there you have it, that’s why. 😂
Okay jokes apart, in a nutshell in today’s modern day and age, internet is at the heart of every product in some way or the other and well, web-development is what empowers you to pursue a career where you can build tools and what not for the Internet first hand. And on top of that it is very easy too, to get started with. It has a massive community to help you. Web-applications are the most accessible form of applications which literally requires just a simple browser. And in today’s modern day and age, with concepts like Progressive Web Apps (PWAs) it is easier than ever to make our applications act like native applications regardless of the platform and operating system they are running on. So you see, what I told earlier was in some extent true, “Web-Development is the best”. 😉
This blog is going to be a long one, so if you are in a hurry or simply looking for the keywords that you need to keep in mind about learning web development in a broader sense, here they are in order of which one to learn first -
And basically that is everything what we are gonna talk about in this blog. In the upcoming sections, we are going to dive deep into every step that I mentioned above and discuss about how to start and eventually be good enough to build your own web applications. So buckle up, grab some popcorn and relax, as its gonna be a long ride.
(Understanding what happens behind the scene when we load a website in our browser)
Before starting with web-development at the first place, we should understand why we need to follow the roadmap that I outlined, or in other words find the motivation to why should we follow the road-map. So here arrises the question, what actually happens behind the scene when you provide a URL in the address-bar of your favorite browser ?
In a broader sense, this itself is a humungous topic that will require its own blog to cover all the corners, but just for the sake of this blog, in simple words, three things happen when you navigate to a website -
(Simplified just for the case of this blog)
Server - **Just as the name suggests, it serves to the requests made by the client.
**Client - The device from which the request is being sent and the device that accepts the response from a server.
Request - In simple words, it is what a client asks the server to provide, with some context.
The client (in this case your favorite browser) sends a request (in this case it will look something like "load https://arunabharjun.com in my browser") to the server.
The server sends a response in context of that request to the client. (In this case sends you the server side rendered website)
The client then displays that response for the user to consume. (in this case the website you requested to load)
It is obvious that a request really doesn't exactly look like "load https://arunabharjun.com in my browser", but for the sake of understanding, you can imagine the client and server communicating with each other in some form which reciprocates "load https://arunabharjun.com in my browser".
Now you see, in reality there is a lot that goes behind the scenes but we can sum it up to two terms in a broader sense -
1. Frontend (Everything client)
2. Backend (Everything server)
So what you see with your eyes and interact with directly in a website after it loads in your window is the frontend, and everything that works away from your sight, basically the thing that provides you with the website is the backend. Now I am not going too much into details, but hey, google is always there right? If you are a curious kid, just open a new tab and you know what you need to do. 😛
So with everything that you have learnt from this discussion, I hope you are feeling motivated now to follow the roadmap, as simply put, the knowledge of static websites help you understand dynamic websites which have a more robust backend that drives the frontend and then there are two ways to achieve that (monoliths and micro-services) which we will discuss in more details in the coming sections. Okay I know what you are saying, "enough with the pre-requisite part Arunabh, just let us know what we need to learn and from where to", and thats exactly what I am going to discuss now.
Now if you are someone who wants to orient themselves with just backend and really doesn’t wanna worry how the data sent from the backend is being represented in the frontend, then you technically could think about skipping this part but, in reality, even if you are specifically a backend developer, it will help you a lot if you have knowledge about the frontend part too.
So now that we have that out of the way, lets understand more about static websites.
HTML - Hyper Text Markup Language
CSS - Cascading Style Sheets
A static web page (sometimes called a flat page or a stationary page) is a web page that is delivered to the user's web browser exactly as stored, in contrast to dynamic web pages which are generated by a web application, is the wikipedia definition. So basically it is just the simple hard coded HTML page that the server sends to the client just as stored in the server without any changes at-all. What the developer has coded is what you get to see in your window.
So a static website, while could be just a HTML page, but HTML alone does-not have the ability to format the document, well at-least not in as robust way, as we might want to. That is achieved using CSS. In simple words, what plaster and paint is to bare brick walls is what CSS is to plain HTML. Now HTML & CSS together make the website pretty and presentable, but what about the functionality? To understand what I mean by functionality, let us take the example of a wall again. So you might have seen there are windows and doors in walls, but they are rendered useless without the hinge mechanism and all the other bells and whistles that come along with the doors and windows and that is exactly what JS brings to the table for vanilla HTML documents. JS makes the website gain more functionality. So in a nutshell, to make a bare minimum static website with hardcoded pages and some pretty formatting along with some functionality, you will need to know HTML, CSS & JS.
I recommend that you learn them in the following order -
After getting your hands dirty with the ones above, I would like to get you interested into a web UI framework called Bootstrap. It is a very popular UI-library / framework which is easy to learn and helps you understand most of the conventional terminologies of UI elements that are used in mainstream frontend web-development. Find the resource for Bootstrap as follows -
💡PRO TIP : After going through with all the above mentioned, download a Bootstrap free website template and try to recreate the complete template on your own.
While the above resources are really great and best in my opinion to get started with, but do not limit yourself to them. Feel free to explore more as you like.
This is the new way of developing frontend websites. There is something called a Single Page Website (SPAs). And that is where libraries/frameworks like React.js, Angular & Vue.js shines. Okay, I know, I just jumped ahead and started throwing a lot of terms. Don't worry, we together will understand them one by one.
Well the full form is "Single Page Application". In simple terms, a SPA is a kind of app that contains all the pages/views/screens of app, in one single page, but libraries and frameworks help us develop them in a way that they appear to be having multiple pages with links among them that help us navigate around. We can take the example of YouTube. You might have noticed that lately when you navigate from one page to other or say open a video, YouTube does not reload the webpage at a browser level, but simply takes you to the video page and shows the loading progress on the top as a red progress bar.
They are generally faster to load than a static HTML website as most resources involved in the page loads only once. Rest of the data either loads dynamically or simply moves around.
It is much easier for the developers as the libraries & frameworks make code reusability possible and in general debugging is easier using variety of tools available.
So by now you have seen me talk about two things in particular a lot, framework & library. The reason behind that is that here a framework is the one that provides a very strict set of ways that will achieve the end goal, but a with a library, you can achieve the same goal with totally different kind of methods and steps. And that is what sets the difference between React.js, Angular & Vue.js, where React.js is a UI library & Angular, Vue.js are UI frameworks. Now they are not the only libraries or frameworks but they certainly are the most popular out there. And which ever one or may be more than one you choose to proceed with, you are good to go.
Well there are a number of resources you can choose from, and I believe they will all teach you the library or framework good, but the best way to get started is by taking a look at the official documentation provided by these organizations.
Official Documentation -
Angular : https://angular.io/docs
Vue.js : https://vuejs.org/v2/guide/
React.js is developed and maintained by the Facebook team
Angular is developed and maintained by the Google team
Vue.js is not developed & maintained by any one Organization
💡PRO TIP : If you went the React.js way, try to explore Next.js after getting your hands dirty with React.js
So by now everything that we have discussed is only about building the client-side application, or simply put, the frontend part. But unless the website is a static website or may be a dynamic website too that does not require us to fetch data from a database, we will need a backend that sends us the data that we need to display in our client-side application and also to send the data from client-side to our server and finally to a database. Now, notice that I have mentioned the word database many times here, but what is a database ? Lets find out.
The wikipedia definition of a database is -
A database is an organized collection of data, generally stored and accessed electronically from a computer system.
Simply put, it is where we put the data or information generated by or for the application we are building. And there is not only one THE DATABASE. There are a number of databases out there which are being used in all kinds of applications. And the categories in which they are divided into are a lot but to name the most commonly used are -
- Distributed Databases
- NoSql Databases
- Relational Databases
Now the discussion about all these types of databases is a complete different blog to write, but if you are curious to know, feel free to go ahead and make a google search on "types of databases".
So now that we have discussed about what is a database, you might be thinking "yeah, yeah... all these are fine, now tell me where do I start if there are so many types of databases". And don't worry, that is exactly what we are going to discuss now.
Now as much simple as it seems like, the answer to this question is not that simple. Different types of databases have different usecases and completely different ways to interact with them. But just to get started I will suggest that you learn MySQL and MongoDB. Now it might seem bit oppinionated, but learning these two will give you good understanding of a Relation Databse (MySQL) and a NoSQL database (MongoDB) and then you will have enough knowledge and understanding of how a database works and then you can branch out even more deep and learn a number of more databases.
You can use the following resources -
As always, dont restrict yourself to only these resources, while they are good enough, do go ahead and explore a little bit yourself. Remember, Google is your best friend.
Now that we have explored frontend, and databases, we need to learn backend which connects the frontend part with our database.
💡PRO TIP : Do explore Firebase (A Backend-as-a-Service by Google).
Simply put, backend is the bridge between our client-side application and the database. But just like databases, there is no "THE ONE BACKEND". There are a lot of different ways to go with, while thinking about which language to learn while starting backend, as backend doesnot have any language of its own, but different languages offer ways with which we can write backend code. Okay, so I feel that all these information is kind of not making much sense to you righ? Dont worry, lets make it little bit simple to wrap your head around.
What is the objective of writing a backend ?
The answer is that we want to take data from client side, do something with it, and then either store that data to the database or send it back to client, or may be simpy fetch data from the database and send it to the client. In simple words, do everything to the data before storing it in the databse and sending it to the client side.
How do we achieve that objective ?
We write some code that lives in our server, and that code acts as our backend service which processes the data for us.
How do we write that backend code ?
We can write this backend code with a number of languages, and achieve the same end goal.
What all languages are there with which we can write backend code?
Now this is a interesting question, as there are a lot of them, but just to state a few of the mainstream ones -
- C, C++
- Objective C
And the list goes on ...
Which one should I choose?
This really will differ from one person to another, but a very simple way which I think is to make this decision is by asking yoursef this question -
Which languages do I know already out of all these and which one is my favourite out of them ?
Which ever comes in your mind, go ahead with it and you shoukd be good to go. Still if you are not sure, may be do a google search of what is the language most in demand for different kind of job openings and choose according to that.
Node.js Learning Resource : https://www.tutorialspoint.com/nodejs/index.htm
And, now finally after learning Frontend, then storing data in a Database and connecting them with a Backend, you are a Full-Stack developer. But wait, what is "Full-Stack Developer" ? And the answer to that question is, a developer who can develop both client-side and server-side software, in other words a person who can write code for developing both frontend & backend is a Full-Stack developer. But does learning just these three make you a full stack developer? Well technically it does, but in reality there is a lot more to this. So lets take a look at what all we have covered as of now, and what all is left -
Now even though having learnt all these does entitle you to call yourself a full-stack developer, but let me ask you a question. What is the real objective behind learning all these? And the answer to this question is quite simple, its building real world web-applications. And while we might not really realize it, but in todays world, a web-application is intended to be used by a huge number of users and that really depends on what service the web-application is providing. But the main thing to understand here is that the applications that we develop should be able to accommodate as many users as needed and it would be a very bad idea to limit the number of users that can use the service. But why even am I telling you all these things, by now you might have thought that "okay, I will get as much storage space in the database require and let as many users use it" right ? But here the bottleneck is not really being enforced by the capacity of database, but the server that is going to serve the data. Okay, I am assuming that some of you would get confused by now so let me make it simple for you -
You might be thinking, when did we cover "Monolith"? The last thing we discussed about was backend. Well if you recall everything that we have been discussing till now, I only mentioned "Server" as a singular word and never used the word "servers", and that is because everything that we have been learning up-till now has only one server that connects the database and client-application. And this kind of application is known as a Monolith. And thats what we have been discussing about from the very beginning, so without even realizing it, we have learnt what is a Monolith. So it basically is the kind of application that have all the features baked in one server/program. Here is the wikipedia definition -
In software engineering, a monolithic application describes a single-tiered software application in which the user interface and data access code are combined into a single program from a single platform. A monolithic application is self-contained and independent from other computing applications.
But a server is just another computer sitting somewhere far from us which is accepting and serving requests. And that computer has its own limitations, just like the one you are using to view this blog right now. So there will be a certain number of requests that a server can process and if ever the time comes that there are more requests than the server can process, the server might become unresponsive and that is what we mean when we say "The server went down" or "The server failed" etc. So now you see, the bottleneck is being enforced by the capacity of the server to process requests and not by the capacity of database. And this is a very bad event if it occurs as there can be a number of services and features that are running on that server and even a simple request can bring the whole server down, thus creating one single point of failure. And so, I again ask you the question, Does learning just Frontend, Backend & Databases make us Full-stack developer ? And as harsh the answer might sound, but the answer is NO! It does-not. But don't worry, we together will fix it.
So one answer that might pop in your head is that "why don't we have multiple copies of the server and distribute the requests among them", and that would work to some extent, but there is a better solution to this problem and is kind of based on this answer. And that solution is Microservices. And it is quite similar to what came into mind at first, but the difference here is that we separate the features that were earlier baked all into one server and create different servers based on single features. And thus the name shifts from a server to a service, as each of the servers now serve only one small service and thus are called Micro-Services. Okay, so all of this might not make much sense now, but we will discuss this in details in the following section.
Now, microservices have a lot more going into it than simply making multiple servers. And there are a lot of different ways to go about it. Here I will discuss how we can do it with Docker & Kubernetes.
Without going too much into details, it is a program that lets us make virtual machines which are very light weight. Those are called containers and we can use each container to deploy one micro-service.
While docker has a lot more use-cases than what I mentioned here, but for the sake of this discussion, we will limit ourselves to what I just now said. Here is the wikipedia definition -
Docker is a set of platform as a service products that use OS-level virtualization to deliver software in packages called containers. Containers are isolated from one another and bundle their own software, libraries and configuration files; they can communicate with each other through well-defined channels.
With respect to our use-case, we will use Kubernetes to maintain and manage the containers that we create as our micro-services. Here is the wikipedia definition -
Kubernetes is an open-source container-orchestration system for automating computer application deployment, scaling, and management. It was originally designed by Google and is now maintained by the Cloud Native Computing Foundation.
Now there are a lot of things to learn if someone wanted to learn everything about them, but just for the case of Microservices, I will suggest a Udemy course which helped me learn all about Microservices -
Microservices Course : https://www.udemy.com/course/microservices-with-node-js-and-react/
And basically that is it, if you have followed this guide, you my friend can call yourself a good Full-Stack developer.
Web-development is a very vast thing to cover and there is not "THE ONE" correct way to go about it. And it is going to be a big but worth-it journey. And believe me, there is something new that you will learn every day. The world is shifting towards web-based services and it is time now that you too move along with the world. And with that, I conclude my blog and wish you all the very best.
There is a lot more to web-development and this blog obviously doesn’t cover 100% of it, but it sure covers a part of it. Do make sure you never restrict yourself from exploring and researching as much as you can. The more you will explore, the more you will know.
Feel free to contact me for doubts or comment them down below.