Forem: Arunabh Arjun

UX design 📱 and Puppies 🐶

Arunabh Arjun — Sun, 30 May 2021 08:29:46 +0000

"A design thinking approach"

🌟 Introduction

I know that the title of the blog is not one of the usual ones, but we will get to that later. Let's first establish what we will focus on in this blog, and that is to elevate the User Experience (UX) in your next revolutionary product with some unorthodox design thinking approach for your User Interface (UI). Well, I guess "unorthodox" was quite established when the title had both the words, "UX" and "Puppies" in it 😅. And by now you might be all wondering how do UX and Puppies relate, allow me to explain -

🐶 Why and how Puppies ?

We all love how the very friendly and loyal friends of us humans, play with us and it just is so much fun. One can say in very unusual words, "it's very intuitive" how playing with the puppies come naturally to us, humans. Not to mention it's somewhat similar to how a pet cat plays with us too. This is explained in much finer details in the paper "Pet Face: Mechanisms Underlying Human-Animal Relationships" by Marta Borgi and Francesca Cirulli, which if you are interested, can find here - https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4782005/. And in brief, this paper is trying to explain that how a puppy having similar facial cues with a human baby 👶 makes humans develop a similar kind of affection with their pets that they have with their babies. Well I know, you didn't come here for a human and pet relationship analysis, so here is what I want to convey to you having said everything that I have said till now in this blog -

Just like how humans develop affection for puppies that have similar facial cues to their babies, it is natural for humans to develop likability for our products that can somehow provide an experience that is more organic in nature and similar to things that they see around them.

Well now you see where I am heading with this, it’s all about making users of our product fall in love with it just like how they love their pet puppies. And let’s exactly discuss how even this design thought process can be realised.

😎 Character Development

This continues with the thought process that we developed just now. A product can look awesome and have great functionality, but what brings that x-factor of likability is how the UI and the UX together takes shape of a character that the users can more relate to. Picture this, whenever you think of a doctor, the chances are that an image forms in your head instantly with a person wearing a white coat and a stethoscope hung around their neck. And so is the case when you think of Google, where you think of fun and colorful illustrations & doodles, which are very relatable, or if you take the example of Apple inc. , there are chances that you think of a sophisticated professional environment with itched glass walls and white aesthetics. This is similar to how a mascot becomes the symbol of a sports team. A major role here is being played by the branding associated with the products, and how they are positioned in the market. This helps a company or a product build relatability with the users and ultimately become the first thing that pops in their head when they are trying to accomplish a goal that can be made easy with the help of your product. So while developing your next product, try creating a character out of it, and keeping the UI design in sync with the character. This eventually adds up to a great UX and chances are the users will start seeing your product as a permanent solution to their problem. 🎉

🥊 Feedbacks & Micro-interactions

The third law of Newton states -

To every action, there is an equal and opposite reaction

And how can we forget that while making the UX have a more organic feel when we almost constantly are in a touch with this law in real life. Even when we are not doing anything, our body is experiencing atmospheric pressure and the body is exerting an equal amount of force to cancel out the force your body is feeling from the atmospheric pressure. But how do we bring this to the UX of our products? The answer is by very cautiously designing the micro-interactions and the feedbacks that the user will receive while using your product. This really is the most fundamental way to making conversation with your user via your product. You can think of a product that has no feedbacks and micro-interactions, like talking to that, out-of-league girl or guy you might have ever tried texting and never got a reply back 😭. Well, it is a really bad feeling to experience... I remember that day when I was in my college, I finally got the courage to pick up my phone and...

Wait, wait, wait ... I guess I got a little carried away there 😅, but the point is we don't want the users of our product to feel the same right? RIGHT? So to make the conversation flow between the users and your product, sprinkle in the magic of micro-interactions and feedbacks, and viola, your product has a great UX. Much like how a puppy reacts to head scratches and belly rubs.

😇 Reliability Factor

Everything that we have discussed by now is all really great to elevate the UX of your product, but to see them in their full effect, the product needs to be reliable in nature too. Now reliability is a quite big term and that might encapsulate and include a significant amount of technical details of the backend, frontend, and systems architecture, but in this case, we are only focusing on the reliability of UX in terms of the UI. And the last cherry on the top is ... (drumrolls 🥁) ... timing and placement!. The feedbacks and micro-interactions will render themselves useful only when they are timed correctly. What this means is, if we take the example of a hover interaction, the micro-interaction has to be designed in such a way that the effect is evident instantaneously. This thought process also carries forward to feedbacks as a feedback is only received when the receiver is aware of the context of the feedback. If we take an example of a hand-eye coordination task, the feedback should be provided via some method where the hand can receive it or in a place where the eye is pointing to. This design thinking approach builds up to the reliability of a product and hence elevates the UX.

🚀 Conclusion

While trying to communicate the value of your product, as important it is to highlight the functionalities, it is equally important to concentrate on the way the UI is presented to the user with the minimal possible steps to achieve an end goal and also it should look familiar to things user are used to seeing every day so there is less learning involved. While the functionality solves the problems of the users of your product, the UI of your product paves the path to how the solution makes sense. And eventually contributing to a great user experience. So next time you are designing your revolutionary product, take a walk, play with a puppy and then start designing. And always remember -

UX tells a story, a story written in the language of feedbacks and conversions...

~ Arunabh Arjun

www.arunabharjun.com

How to develop Apps like Netflix

Arunabh Arjun — Sat, 13 Feb 2021 10:50:20 +0000

Empowering your OTT platform client-side with the likes of Netflix

🏁 Introduction

You have a weekend off and you slip into your cozy couch and think that you are finally going to start working out today, but then you look at the TV in front of you and fire Netflix, and the next thing you know, you have binged for 8 long hours and the weekend is nearly over. Does that sound familiar? And does that happen every week? Well, I don't know about you, but definitely, that is my typical weekend. But then suddenly one day it struck me, what if I wanted to have my own Netflix. What if I brought another platform like that and then in place of binging on Netflix myself, I leave it up to you to binge on my platform. Sounds exciting right? Well, as exciting as it might sound, it's way more than the idea. And a major factor in that is the technology that goes behind. But that is where this blog comes in. Sit back and relax, as we together will find out, how to OTT!

📺 But what is OTT?

While it means "Over-The-Top", it might not be very clear what it signifies. In very simple words, it is the technology that empowers you to enjoy the likes of Netflix, Amazon Prime, YouTube, and what have you. So if you are thinking about starting your own service like Netflix, what basically you are talking about is building your own OTT service. So let's do exactly that, shall we?

🎬 Where to start ?

Well, before the blog starts becoming all technical, what we need to understand is that an OTT service today needs to be available on a variety of platforms, and to name just a few, we have Apple TV, Android TV, LGTV Web OS, Samsung TV Tizen and of-course personal devices like phones, tablets & laptops. And while that might sound like a hand-full, one can never go wrong with the saying-

"One step at a time"

So lets take the 1st step and dive deep into how to build the frontend of an OTT platform.

📱 Building the Client-Side / Frontend

So, going back to the headline of this blog, "Empowering your OTT platform with likes of Netflix", what actually empowers the frontend of Netflix? And the answer is React.js. And the immediate next question is "What is React.js ?". And the answer is, it is a frontend library built by the folks at Facebook. But the story doesn't end here. While React.js is THE solution when we talk about an OTT service, just like I have mentioned earlier, we need to take care of many different platforms, like the Web, TVs, Phones, etc. But don't worry, lets together take a look at how React.js applies to all these different platforms -

1. The Web

What does really "the web" mean? Well, in today's modern-day, the fastest way to give consumers access to a service is by making the service available via "the web". Regardless of the device, just a simple browser and access to the internet is all one needs to access the service. And React.js alone takes care of that frontend wise. And additionally, React.js covers a wide array of platforms like phones, tablets, laptops, and even Smart TVs that support access to the internet and a browser. But React.js has a lot more to offer under the hood. And while the web version could cover a big array of platforms, we can still build native solutions using React.js, so let's see how that really works.

2. Phones & Tablets

A major share of phones & tablet platforms revolves around the offerings of Android & iOS/iPadOS devices. And the good news is that we can use React Native, which is a version of React.js, that enables the development of native apps while sharing the same codebase across many platforms. And just like that React.js again saved the day.

3. Smart TVs

Now the main motive behind starting an OTT service is to make your platform available in modern Smart TVs and to be frank, there is a big array of platforms with their own OS that have different development cycles. But again, React.js is here to the rescue. With the power of React.js & React Native, it is easier than ever to build for most of the platforms, like Apple TV, Android TV, LGTV & Samsung TV. So let's take a look at how exactly we can achieve this -

Using React Native

React Native is a very powerful tool that covers the likes of Android TV & Apple TV which can share the same code base.

Using Enact

While Android TV and Apple TV have a very straight foreword approach, LGTV and Samsung TV do not. LGTV runs on WebOS and Samsung TV runs on TizenOS which is their own solution for their Smart TVs. And while it might be surprising to many, we do have a solution that enables us to use the same codebase with very minimal tweaks to make Native Apps for both platforms. And that is made possible by the folks at LG, who developed a framework called Enact which is built on top of React.js. And just like that, React.js even covers LGTV & Samsung TV.

🌟 Conclusion

So by now, you definitely have grasped the idea that getting to know the React.js library is a good place to get started. And surely will take you one step closer to your dream of starting your own OTT service and maybe finally start that work-out that you have been thinking about 😛.

Written By -

Arunabh Arjun
www.arunabharjun.com

Creating infinitely scrolling SPA using React

Arunabh Arjun — Fri, 30 Oct 2020 17:39:11 +0000

Introduction

Before starting with this blog, check out this to get the best idea of exactly what we are trying to achieve -

https://articles-app.arunabharjun.vercel.app/

So you have experienced infinite scrolling in apps like instagram, facebook, linkedIn, etc. wherein as soon as we reach the bottom of the page, more data loads, unless obviously there is no more data to load. And that feature is really kinda cool, isn't it? And you would like to implement that in your web-app too but have been wondering how to achieve that with your React.js app. We all love and adore how React.js simplifies dynamic client side web development for us, and we all are familiar with the common hooks like useEffect & useState, but React.js has a lot more under the hood, and today we are going to explore another hook which is called useRef and how we can use it to achieve infinite scrolling within our React.js application. So lets get started, shall we?

Short version of this blog

If you are someone who is just looking for the best method to use while implementing infinite scrolling and do not have a lot of time to read through a complete blog to understand the reason behind why we are choosing which method (which btw you totally should go through) here is the short answer to that :

Avoid trying to detect if the bottom of the page is reached or not.
Implement logic to detect if the last element from the dynamically rendered elements is in the viewport (visible area of your browser).
This has to be achieved using the useRef & useCallback hooks and storing reference to the last rendered element.
As soon as the last element is visible, re-fetch the next page of data (paginate).
Render the new data just bellow the existing elements.
Remove previous reference and re-assign reference to the last rendered element for the new data .
That should make the loop going on with infinite scrolling.
Check if there is any more data to fetch, if not, remove the reference to last element and do not assign it to anything and display prompt for no more data to load as you wish.

Github repo link - https://github.com/arunabharjun/articles-app

Okay so now that we have that out of the way, for those who got lost in the short version and are wondering what in the world am I talking about, don't worry, as we together will understand step by step along with code example what exactly is going on. But to understand that, we need to make sure we know what goes on behind the scenes when we render something in a React.js app and refresh ourselves with the underlying concepts of React.js .

So what is Virtual DOM in React.js

It is the in memory representation of the currently rendered elements in the React.js app and is synced with the “real” DOM using a library, like the ReactDOM.

A more detailed description can be found within React.js official documentation. As of writing this blog, the link to that is as follows -

Virtual DOM and Internals - React

Why do we need to understand this ?

Now the reason that I am bringing up the discussion abut the Virtual DOM in React.js is that I have seen that there is a tendency among us, the developers, while developing a React.js app, to forget about how the stuff is getting rendered as the states change and we simply get comfortable with the idea of letting create-react-app show us its magic and do what it does. And that might work for most small, less demanding projects, but for projects that require more than that, it is crucial that we understand what is going on under the hood when we are rendering UI elements in the React.js app.

Now having said that, and having understood what is Virtual DOM in React.js world, let us finally ask the question, what happens under the hood when we render UI elements in a React.js app? Let’s find out.

What happens under the hood in a React.js app

While we can go into in depth details on how re-rendering and infinite loops of renders can occur in a React.js app, but that is out of the scope for this particular blog. But in a nutshell, what happens under the hood is that React.js maintains a tree of UI components where every UI component have UI elements as their nodes and that UI element can in turn, again be another UI Component that has more UI elements inside that. So basically it can be visualised as a hierarchy of components within components and so on. But the key thing to note here is that we can visualise each UI element as a NODE of UI components tree. And that is what is going to help us understand why we are going to use the useRef hook to achieve infinite scrolling.

To understand about this in more details, React.js has an excellent blog in their official blog post page which you can give a read. The name of the blog post is React Components, Elements, and Instances and as of writing this blog, the link is as follows -

React Components, Elements, and Instances - React Blog

So now that we have brushed up on the basic concepts that we would require to understand the use of useRef hook in React.js, let us jump back to the goal of this blog, ie. implementing an infinitely scrolling SPA using React.js .

Possible logics that we can use to achieve infinite scrolling

Detecting if the page has scrolled to the bottom of the page, and then loading new data and rendering it and that way achieving infinite scrolling.
Checking if the last element rendered is in the view port (the visible area of your browser), and fetching new data when this condition is true and re checking if the last element is again visible in the viewport and this way the loop continues for infinite scrolling.

Problem with the 1st solution

Now while both the methods might seem like they would work, and in a lot of cases, they surely will, but there is a problem with the 1st solution. And that is it limits our implementation to only listening to the page scroll state, where we only load the data when we are at the very bottom of our page, and in many cases, it can trigger an infinite loop of the same request, eventually getting an error response from the server saying “429 : Too many requests”. And apart from that, you will encounter a number of many other issues too if you go the “detecting if page bottom was reached".

Why the 2nd solution is better ?

Now the second solution is much more flexible, and we can modify the logic to a lot of different iterations of it, like for example, we could also implement our own pull down to refresh page where we implement a UI element to not show by default and only show up when we pull down further, and as soon as the pull down element is in the view-port, we can refresh the data in our page. And that is just one example that I stated, but with this approach, you can think of more creative ways to trigger pagination/page-refresh/etc.

Also the second approach is the “React.js way” of doing it

Now that we have discussed why the second solution is in general a better approach, I believe it is time I can safely say that there is another good reason to make use of the second approach, and that is it allows us to achieve stuff the React.js way and not vanilla JS way, and to be honest, if we were to do everything the vanilla JS way, we would loose the significance behind using a UI library like React.js at the first place. And the React.js way to achieve infinite scrolling is by using the useRef hook to save reference to the last element that was rendered and do operations on that as we desire.

By now I have mentioned the useRef hook many times, but you might be asking, “Arunabh, what is this useRef hook that you keep talking about?” Let’s find out.

What is “ref”, “useRef” & "useCallback" in React.js ?

Now, just like useState & useEffect, useRef is another hook which returns a mutable object. The returned object persists for the full lifetime of the component on which it is being used, unless instructed to do otherwise.
Along with useRef, we are going to use another hook called useCallback that returns a memoized callback. It is something similar to useMemo, but for the purpose of achieving infinite-scrolling, we can safely use useCallback which you will understand how to in the later section of this blog.
Now I hope you remember that we discussed about how React.js maintaines a tree of UI components and we can visualise each node to be a child component, and those nodes can be referred to, or in other words, we can pass reference to those nodes using the "ref" attribute in our component.

You can find out more about them from the official documentation of React.js. As of writing this blog, the links to that is as follows -

Hooks API Reference : useRef - React

Hooks API Reference : useCallback - React

Hooks API Reference : Documentation - React

Now these all might be appearing to be little confusing for now and you might be asking the question, "well how do we use them all together to achieve infinite scrolling ?". Lets find out.

Implementing infinite scroll

1 The first step will be to import the hooks, so lets get that out of the way

import { useRef, useCallback } from 'react';

2 Now for the sake of simplicity, I will assume that you already know how to fetch data from an API and have data in your state already populated, and also are aware how to re populate data using pagination, so I will go straight to the part that deals with implementing infinite scroll.

3 So now, we will be setting up an observer which stores the object returned by useRef hook.

const observer = useRef();

4 Now we will setup a function that stores the memoized callback function from useCallback hook to perform operation on the observer that was created in the last step.

const lastComponentRendered = useCallback(
        (node) => {
            if (loading) return;
            if (observer.current) observer.current.disconnect();
            observer.current = new IntersectionObserver((entries) => {
                if (entries[0].isIntersecting) {
                    fetchSomeData();
                }
            });
            if (node) observer.current.observe(node);
        },
        [
            loading
        ]
    );

5 Let us breakdown the code in step 4. So we are returning the callback to the constant "lastComponentRendered" and passing a node (which you will understand how it works in the following steps).

const lastComponentRendered = useCallback(
        (node) => {
            //do stuff
        },
        []
    );

6 Now to avoid infinite re-rendering, we need to keep a check if data pagination has already begun, and that is being stored in our "loading" state, which I will leave at you to implement as you wish.

const lastComponentRendered = useCallback(
        (node) => {
        if (loading) return;
        //do stuff
        },
      []
    );

7 Now since in the 3rd step, we didn't pass any argument with the useRef hook, our observer will initially have a value of undefined and so we check if observer is undefined or not.

const lastComponentRendered = useCallback(
        (node) => {
            if (loading) return;
            if (observer.current) observer.current.disconnect();
            //do stuff
            },
          []
    );

8 Now we reset the current property to be an instance of an intersection observer which basically holds an array of elements and returns true from the callback if the argument passed in the callback intersects with the view-port, in easy terms, lets us know if the UI Component is in view-port or not, when we check it with isIntersecting function. To know more about intersection observer, check out this https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API.

const lastComponentRendered = useCallback(
        (node) => {
            if (loading) return;
            if (observer.current) observer.current.disconnect();
            observer.current = new IntersectionObserver((entries) => {
                //do stuff
            });
            //do stuff
        },
        []
    );

9 Now we simply check for the first element in the array of entries that we passed as argument in the callback function in IntersectionObserver() and se if it intersects.

const lastComponentRendered = useCallback(
        (node) => {
            if (loading) return;
            if (observer.current) observer.current.disconnect();
            observer.current = new IntersectionObserver((entries) => {
                if (entries[0].isIntersecting) {
                    //do stuff
                }
            });
            //do stuff
        },
        []
    );

10 And if it does intersect, we simply paginate the data. I will leave it up to you to implement the pagination logic. Here that is being represented by the function "fetchSomeData()".

const lastComponentRendered = useCallback(
        (node) => {
            if (loading) return;
            if (observer.current) observer.current.disconnect();
            observer.current = new IntersectionObserver((entries) => {
                if (entries[0].isIntersecting) {
                    fetchSomeData();
                }
            });
            //do stuff
        },
        []
    );

11 Now we simply observer's current property to observe the node that we passed as argument while calling the useCallback hook in the 4th step.

const lastComponentRendered = useCallback(
        (node) => {
            if (loading) return;
            if (observer.current) observer.current.disconnect();
            observer.current = new IntersectionObserver((entries) => {
                if (entries[0].isIntersecting) {
                    fetchSomeData();
                }
            });
            if (node) observer.current.observe(node);
            //stuff done
        },
        []
    );

12 And just like the useEffect hook, we can pass a second argument as array of states on which the hook will depend and will only execute if there is a change in any of those states, and we pass the "loading" state for this purpose as we don't want it to execute for every re-render in the React.js app.

const lastComponentRendered = useCallback(
        (node) => {
            if (loading) return;
            if (observer.current) observer.current.disconnect();
            observer.current = new IntersectionObserver((entries) => {
                if (entries[0].isIntersecting) {
                    fetchSomeData();
                }
            });
            if (node) observer.current.observe(node);
            //stuff done
        },
        [
            loading
        ]
    );

13 Now the only thing left to do is simply pass a reference of a UI Component (node) to "lastComponentRendered" using the "ref" attribute and see the magic happen.

return (
        <React.Fragment>
            <div className='container'>
                {fetchedData.map((data, i) => {
                    if (fetchedData.length === i + 1) {
                        return (
                            <div
                                ref={lastArticle}
                                key={i}
                            >
                                <YourCustomComponent>
                                    {data}           
                                </YourCustomComponent>
                            </div>
                        );
                    }
                    else
                        return (
                            <div key={i}>
                                <YourCustomComponent>
                                    {data}           
                                </YourCustomComponent>
                            </div>
                        );
                })}
            </div>
        </React.Fragment>
)

14 And this step is very self explanatory, but for a better clarity, we are checking if the currently being rendered UI Component is the last one by checking if the length of "fetchedData" (which is the state that stores the data we fetch from our data source) is equal to the number of iterations that took place. And if that condition satisfies, we pass a reference for that UI Component using the "ref" attribute.

Full code implementation

I have implemented the logics that I explained in this blog in the following code. I encourage you to take a look at it to get an idea of the complete working of the concepts mentioned. The link is as follows -

arunabharjun/articles-app > Full-Code

You can also go ahead and clone the complete repo to get more in-depth understanding of the implementation. The repository README file has detailed explanation on how to get started with the project.

arunabharjun/articles-app

Bonus : Code snipped to detect bottom of page

Well, if you still wanted to see how to detect if the page had scrolled to the bottom or not, refer to the following code snippet.

/**
 * Utility function to listen for scrolling
 */
    const handleScroll = () => {
        const windowHeight =
            'innerHeight' in window
                ? window.innerHeight
                : document.documentElement.offsetHeight;
        const body = document.body;
        const html = document.documentElement;
        const docHeight = Math.max(
            body.scrollHeight,
            body.offsetHeight,
            html.clientHeight,
            html.scrollHeight,
            html.offsetHeight
        );
        const windowBottom = windowHeight + window.pageYOffset;
        if (windowBottom >= docHeight) {
            console.log("Bottom reached!");
        }
        else {
            console.log("Bottom not reached!");
        }
    };

Conclusion

And so now you know how to make use of built-in features of React.js to implement a infinitely scrolling SPA with dynamic data fetching. Like this, there is a lot that React.js brings to the table and the more you explore, the more you'll know. So keep the hunger to explore alive and see you in the next blog.

Written By
-Arunabh Arjun
www.arunabharjun.com

Roadmap to modern Web development | From Static to Full-stack to Micro-services

Arunabh Arjun — Wed, 14 Oct 2020 08:39:52 +0000

Introduction

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 ?

Why Web-development ?

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”. 😉

The Road Map in short

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 -

Static Websites
Dynamic Websites
Databases
Backend
Monoliths
Microservices

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.

Behind the scenes

(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 -

Glossary -
(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.

Static Websites

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.

What is a static website

Glossary -
HTML - Hyper Text Markup Language
CSS - Cascading Style Sheets
JS - JavaScript

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.

Resources for HTML, CSS & JS

I recommend that you learn them in the following order -

HTML - https://www.w3schools.com/html/
CSS - https://www.w3schools.com/css/default.asp
JS - https://www.w3schools.com/js/default.asp

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 -

BOOTSTRAP - https://www.w3schools.com/bootstrap/bootstrap_ver.asp

💡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.

Dynamic Websites

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.

What is a SPA?

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.

Why use SPAs

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.

React.js? Angular? Vue.js?

In a nutshell they are all JavaScript based libraries and frameworks which provide us a set of APIs and methods that help us build very robust frontend code. Each of these have some philosophies that they adhere to strictly that define most of the backbone of the library or framework. They are all developed & maintained by some organization.

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.

From where to learn React.js, Angular & Vue.js?

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 -

React.js : https://reactjs.org/docs/getting-started.html
Angular : https://angular.io/docs
Vue.js : https://vuejs.org/v2/guide/

Fun facts

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

Lets talk Backend development

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.

What is a database?

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.

Learning a Database

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.

From where to learn MySQL & MongoDB ?

You can use the following resources -

MySQL - https://www.tutorialspoint.com/mysql/index.htm

MongoDB - https://www.tutorialspoint.com/mongodb/index.htm

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).

Learning Backend development

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 -

JavaScript (Node.js)
Java
Ruby
Python
C, C++
C#
Objective C
Go
PHP
Perl

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.

Still, if you ask me, I went with the Node.js route as it was not a very big paradigm shift from frontend to backend as they both use JavaScript extensively. Now I believe I am not the best person to recoment resources for all the different languages, as I myself dont know them all, but I will share one for Node.js as that is the one I use -

Node.js Learning Resource : https://www.tutorialspoint.com/nodejs/index.htm

Full-Stack Developer

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 -

Roadmap covered as of now

✅Static Websites
✅Dynamic Websites
✅Databases
✅Backend
✅Monoliths
⏹Microservices

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 -

Monoliths ?

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.

How to solve the bottleneck issue of Monoliths ?

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.

Microservices

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.

What is docker?

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.

What is Kubernetes?

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.

From where do I learn Docker & Kubernetes ?

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.

Conclusion

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.

P.S -

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.

Written By

Arunabh Arjun

www.arunabharjun.com

Developing a Portfolio website using MERN stack (Portfolio for a full-stack developer) - Arunabharjun.com

Arunabh Arjun — Mon, 06 Jul 2020 00:01:56 +0000

Are you a full stack developer & planning to develop your own portfolio website?

(Develop a web application complete with backend and frontend with SSR / Develop a full-stack web application / Develop a MERN stack website)

In this blog, I will try to answer the reasons behind going with the options that I went with while developing my portfolio website, ARUNABHARJUN.COM. If you are a beginner developer, do give Blogaroo - Developing a blogging platform using MERN stack a read as I have discussed in details about the road map to learn a lot about MERN stack. As a bonus, that blog also discusses about Next.JS

So, let's first talk about the website that I am going to refer to in this blog, www.arunabharjun.com which is the new version of one I had earlier, which if you are interested, is hosted here legacy arunabharjun.com.

What is ArunabhArjun.com?

It is my new portfolio website. I developed it using MERN stack along with Next.js. This project is complete with an admin dashboard to manage the website. Like I already said, I had one earlier, which I made four years ago, from the day this blog is posted. Back then, I only used to do frontend development. Since then, I have picked up full-stack development and I realised that arunabharjun.com needed a revamp. Also, one very important thing that I had in mind while planning to develop this is that this time, I needed a Content Management System (CSM) styled website. So, instead of a revamp, I ended up developing a whole new full-stack application.

Technical Specs-

As the title says, I've built this using MERN stack, which means MONGO, EXPRESS, REACT & NODE

BACKEND

Node.js with Express.js
Mongo DB with Mongoose

FRONTEND

Next.js (which is basically React.js with server-side rendering)

Why have an admin dashboard?

Generally, portfolios are static websites, which can fall under a lot of categories, like one explaining why the person should be hired with all their work till that time showcased, or can be a story like or a timeline like depiction of work experience with projects to showcase, etc. And to be frank, I believe there is no right or wrong way. Only the most important thing according to me is that whatever way one chooses to go, the end result should reflect that individual well.

A portfolio website should tell a story to the viewers, and the title to that story should be "What if this person was a website?".

When someone looks at a portfolio without knowing the person, it's their first impression for that person. And in many ways, it's actually like meeting that person for the first time. I have a very good reason to why I think that is. See, when someone meets you for the first time, the immediate activity is that they want to understand you, figure you out the most they can. And at today's day and age, people have very less time to do that, and so first impression lasts. And since its very likely that a person visiting your portfolio has not met you in person yet, the immediate activity is exactly the same as what it is like when they meet you in person, that they will try to figure you out, mostly keeping in mind the reason they visited your portfolio. And the easier you make that process for your visitors, the better is the chance they will find you fit for the reason they are visiting your website.

Now keeping in mind what I just explained, and the fact that we are talking about a portfolio website for a person who is a full-stack developer, what better way can be there to communicate that fact to the visitors, than making the portfolio itself a full-stack application.

Now what does that mean for a portfolio? It means that we can add a CMS to manage and update the portfolio with time. And that is why I developed an admin dashboard, so that I can keep my portfolio updated, with my recent activities so the website always stays fresh and conveys the most accurate possible information to the visitors. For all this to work, we need a backend and frontend, right?

The Backend

In the backend part, I used Mongo DB for the database and Node.js & Express.js with Mongoose.js to implement the APIs, which is why it is a MERN stack project. The reason is very similar to what I said in my earlier blog - Blogaroo - Developing a blogging platform using MERN stack. This whole stack is heavily dependent on JavaScript. And having to write code in the same environment for about most of the project really makes the whole development process much easier. So, now with that out of the way, what we need next is database modals. Following are the exact database modals I implemented.

Database Modals

USERS

To create and update users, authenticate them to access the admin dashboard

ABOUT

To store a small summary which I can update time to time

RESUME

To store my resume and update and modify it as and when required

PROJECTS

To CRUD projects that will be shown in my portfolio
Projects have their images, description, tools used, project link and another link to add anything if required other than the project link
They all have some meta properties, like the project is featured project or not, a sort order value according to which the projects will be sorted

TOOLS

CRUD tools that I use in my projects
These tools get referenced in the PROJECT modal

BLOGS

Just to store featured blogs data that will show in the website

So, now looking at the database modals, it becomes fairly easy to visualise how the frontend is going to pan out. Also, once the schema is defined, rest becomes very easy, as in building the REST APIs. I know this is a very unconventional approach to develop a project, where I didn't not plan the UI, features and implementation ahead and directly went with the database and schema , etc. But there is a good reason why I wanted to make this approach.

Why the unconventional approach?

Now the thing to understand here is that I already had an older version of my portfolio, so I already kind of had an idea what all elements I was going to have in the website. Also, this project was not like other consumer products where there was a through need to pre conceptualize the whole product with UI mock-ups, etc. And the reason why I actually wanted to approach the project like this is again what I said earlier, that a portfolio website should reflect the one, whose it is, well. And I thought it was for the best that I wing it and let the UI/UX take shape as I approach it when I do. This way the UX stays very original and honest to what I am. And since I was developing the backend and frontend simultaneously, I thought it would leave me with a good window to slide my creative freedom in. And while talking about the front end, lets discuss it in more detail shall we?

The Frontend

Like I have already mentioned earlier, this is a MERN stack project, and along with that I used Next,js as the frontend framework. And again, the reason is very similar to what I said in my earlier blog - Blogaroo - Developing a blogging platform using MERN stack. Although at first, I thought I would simply use React.js without Next.js, but then whom was I kidding, Next.js simply brings so much to the table along with the awesomeness that is React.js, Next.js was the way to go. Like I said earlier, this was the part where I just went with the flow while developing. I really believe that this is the reason I was able to express a lot about myself through the website UI design, and frankly I was quite happy with the outcome. While I definitely believe there are so many places where things could improve, and I am going to work on them and keep updating the UI & UX. I also included a bunch of static content in the website along with static assets, and let me explain why.

Why Static Assets & Content?

Now, since the portfolio is a full-stack website, it's divided into two significant parts (frontend & backend) which is going to be hosted in two different servers. Ok, now I understand that many will point out that both can be hosted in the same instance with the apache and other related variables configured accordingly, but that is not what I am talking about here. Sure, one can configure their server in a number of ways in the production and I too, after a lot of thoughts & research on how to balance the cost and performance, went with an option which is a completely different blog to discuss about 😅. But what I am trying to convey here is that ultimately the two are going to be served from some kind of two different end points. Having said that, what happens in case the backend server for some reason fails to respond to the requests being made? Now I know there are many solutions to that but It was a safe option to also have some static content and assets in the client side server which will be served in case backend server failed to respond, or in that matter, even come to rescue at an even of bad internet connectivity where the client side did load in the user's device, but the backends' response couldn't load. And since it is a very small-scale application, loading some static data into the client side was the easiest fallback and made the most sense. But do keep in mind that this solution will not be the best approach for a big scale product, like BLOGAROO.IN. So, at the end, static assets and content was just my way of implementing a better UX in an event of a range of things that can go wrong, and keeping the website full of content for the visitor to view, as if it were a static website at the first place.

And with this, I will conclude what went behind the scenes of building ARUNABHARJUN.COM.

BONUS

For those of you who are curious, here are the dependencies that went into developing ARUNABHARJUN.COM

(I have copied the list of dependencies directly from the package.json file for the following)

BACKEND

{
 // other stuff

 "dependencies": {
  "@sendgrid/mail": "^7.2.0",
  "body-parser": "^1.19.0",
  "cookie-parser": "^1.4.5",
  "cors": "^2.8.5",
  "dotenv": "^8.2.0",
  "express": "^4.17.1",
  "express-jwt": "^5.3.3",
  "express-validator": "^6.4.1",
  "formidable": "^1.2.2",
  "jsonwebtoken": "^8.5.1",
  "lodash": "^4.17.15",
  "mongoose": "^5.9.12",
  "morgan": "^1.10.0",
  "shortid": "^2.2.15",
  "slugify": "^1.4.0",
  "string-strip-html": "^4.4.2",
  "validator": "^13.0.0"
 }
}

FRONTEND

{
 // other stuff

 "dependencies": {
  "@material-ui/core": "^4.10.2",
  "@material-ui/lab": "^4.0.0-alpha.56",
  "babel-plugin-transform-remove-console": "^6.9.4",
  "browser-image-compression": "^1.0.12",
  "isomorphic-fetch": "^2.2.1",
  "js-cookie": "^2.2.1",
  "moment": "^2.26.0",
  "next": "9.4.4",
  "next-cookies": "^2.0.3",
  "react": "16.13.1",
  "react-device-detect": "^1.13.1",
  "react-dom": "16.13.1",
  "react-github-calendar": "^1.0.6",
  "react-pdf": "^4.1.0",
  "react-sidebar": "^3.0.2",
  "react-tooltip": "^4.2.7",
  "react-web-share": "^1.0.7",
  "smoothscroll-anchor-polyfill": "^1.3.2",
  "smoothscroll-polyfill": "^0.4.4"
 }
}

By Arunabh Arjun
www.arunabharjun.com

Developing a blogging platform using MERN stack - Blogaroo.in

Arunabh Arjun — Sun, 05 Jul 2020 23:52:00 +0000

Do you want to learn how to develop a blogging platform?

(Develop a web application complete with backend and frontend with SSR / Develop a full-stack web application / Develop a MERN stack website)

I will talk for both advanced and beginner developers in this blog. So, if you are a beginner 🤓, don't get confused with if you see anything that looks too advance for you. As soon as I am done with discussing the advanced stuff, I will also discuss a roadmap to how to reach that position. And if you are an advanced developer, well you know which part to skip. ☕️

So, let's first talk about the actual blogging platform that we are going to refer to in this blog: www.blogaroo.in

What is Blogaroo?

This is a blogging platform, free for all to use. I created this as a part of my personal projects using MERN stack along with Next.JS. Essentially, I planned it to be simply a blogging platform for my own use, but then I figured, while I am at it, why not let the people use it too. So here it is. A very simple and intuitive platform for you to share your story.

It was an amazing experience building this as I have learnt a lot during the development process and that is what I would like to share today with you all.

Technical Specs-

As the title says, I've built this using MERN stack, which means MONGO, EXPRESS, REACT & NODE

BACKEND

Node Js with Express Js
Mongo DB with Mongoose

FRONTEND

NEXT JS (which is basically React JS with server-side rendering)
It's also a PWA so go ahead and install it as a standalone app in your devices.

To know more, visit ABOUT BLOGAROO

So, why Next.JS?

By now, I had already developed some projects using React.JS and became quite comfortable with the framework. But the only problem with React.JS is that it is a framework that uses a virtual DOM to render the HTML and while doing so, everything gets rendered in the client-side thus when the website loads from the server, it only loads some bunch of JS which is not good for Search Engine Optimization (SEO). And for a blogging platform, it was mandatory to get good SEO. To get good SEO, server-side rendering was important. And that's where Next.JS shines. While being pretty much React.JS under the hood, with some really easy to pick up changes, Next.JS was perfect for this. In the end, I managed to score a perfect 100 in SEO Audit by Lighthouse. Feel free to go ahead and run a test for BLOGAROO.IN and see what you get.

So that was frontend part in a nutshell. But for those who are just getting started with web-dev and mainly frontend development, here is the roadmap to reach a position to build this exact website -

Road map to NEXT.JS : GETTING STARTED

First off, what is at the core of any website? Its HTML. So, if you have not started with it already, it's the best time to go ahead and get started with it. A great resource for that is W3SCHOOLS-HTML.
And what Paint & Plaster is to a bricked wall is CSS to HTML. And a great resource for that too is again W3SCHOOLS-CSS.
Now you must have seen how the doors and windows in houses are useless without the mechanisms that drive them to have some functionality right? Well, that is exactly what JavaScript (JS) brings to the table for HTML & CSS. To get started with JS, again a great resource is W3SCHOOLS-JS. Note: Even though Java and JavaScript have common word Java in them, but that's where the similarities end, as they are completely different languages. Here I just cannot stress enough how much important JS is as rest of the whole thing is heavily dependent on JavaScript. If you didn't catch it yet, all the frameworks that I have talked about in the sections above have ".JS" after them, which means they are simply frameworks written on JS or just have to be interacted with JS. So, while W3SCHOOLS-JS is a great resource, you shouldn't limit yourself to that. Do feel free to go ahead and dig up as much as you can about JS.
A bonus will be learning a CSS framework like BOOTSTRAP. And I know you guessed it, yet again a great resource to learn that is W3SCHOOLS-BOOTSTRAP.
And once you have done all these, I would highly recommend you to just practice developing simple websites, maybe using Bootstrap to get the general idea of the structure of webpages and routing, etc.

Road map to NEXT.JS : THE NEXT LEVEL (pun was definitely intended 😅)

So, by now you are definitely a beginner frontend developer. What you need to do next is get started with React.JS. Trust me, the fun has just begun. While the getting started part was a handful, once you dive into learning a framework like React.JS, it's all up and up and up. But this is only going to be true for those who did the getting started part with complete sincerity, as React.JS has JS in the core heart of it, having a not so strong background in JS might just be the deal breaker that takes all the fun away from it. But who is to say, there are many developers who just wing it and pick it up while learning the framework. So, if you are one of them, kudos, follow along. As I said earlier, the fun has just begun 😎.
So before you start learning React.JS, one wise thing would be to make yourself familiar with NODE.JS. While Node.JS is not required for building just the frontend, but it comes with a package manager knows as Node Package Manager (NPM) which you WILL be using extensively for the next few steps. We will be discussing Node.JS in more details in the coming sections.
After doing that, what you want to do is get your hands dirty with APIs (Application Programming Interface). See! I told you that the fun has just begun. Now API on itself is a bigger term than we generally use it for, to get started with React.JS, what we need to do is understand REST APIs. Now, what is REST API? That is a whole different blog to discuss, so I will leave it up to you to google it. A heads up, you don't actually need to learn how to develop REST APIs to get started with React.JS, JSON-PLACEHOLDER is a great resource to get REST APIs to simply practice while learning how to fetch data from REST APIs using React.JS.

Road map to NEXT.JS : LEARNING REACT.JS & NEXT.JS

I know, I know, I sense the hype, and here is where the hype gets settled. Let's start learning React.JS. To just get the initial flavour of React.js, you can definitely check out W3SCHOOLS-REACT.JS. But this is not going to be sufficient, though it is definitely going to be necessary to kick start the learning process. I highly recommend you to take up online tutorials from whichever platform you are comfortable with. I do like taking up courses from UDEMY. If I were to recommend a particular course, here is one - React - The Complete Guide (incl Hooks, React Router, Redux). But do not mistake my recommendation to be "THE ONE". It is just a recommendation among the plethora of valid recommendations.
Now if you have followed exactly what I told in the previous step, then you already are through both React.JS and Next.JS and you probably now see all the dots getting connected and probably have figured out how to build this exact blogging platform too. And if that's you, kudos 🥳.
And now my friend you can easily pick up Next.JS, and that's it. A great resource is Next.JS's very own DOCUMENTATION.
Finally, go ahead and build your frontend for your very own Blogging Platform.

But wait! Are we not forgetting something?

Remember how I told you about using JSON-PLACEHOLDER while learning the frontend part. Well to get your website up and running, you will have to set up a backend which will serve you the dynamic data from your database to be consumed in your client app. So here you can make do with one of the following two routes -

Either team up with a backend developer to simultaneously develop the backend while you develop the frontend of your website.
OR
Become the backend developer yourself. 😅

Ok, so this might sound like too much work. But believe me, if you have come all this way, the next part is not that hard. So, if you have decided to go with the first route, then it's time for you to get started with the development of your product. And I hope this blog helped you find the answers you were looking for. But for those of you who are going with the second route, which is becoming the backend developer yourself, then follow along. And a nice recipe of becoming a MERN full-stack developer is coming right up!

Now while there are a number of options to choose from while developing a backend, and one definitely cannot go wrong with any of the available options as of the date this blog is posted, but since I went with Node.JS (with Express.JS) along with MongoDB as the database, those two are what we are going to talk about in the coming sections.

So, why Node.JS?

For starters, it's a JavaScript runtime environment. And being JS, there was not one-second thought for me. It had to be Node.JS. Moreover, with Express.JS which as stated in their very own WEBSITE, is a Fast, unopinionated, minimalist web framework for Node.JS. And as the frontend is also written using a JS framework, it would be very easy to build the REST APIs while being in the same paradigm of language, i.e. JS. Having said that, now I'll answer the question to why I choose MongoDB.

Why MongoDB?

The reason is very similar to "why Node.JS?". MongoDB is a database that stores the data in the form of JSON (JavaScript Object Notation) like documents. And again, JS shines. As MongoDB stores data in an identical format to what we get as a response from REST APIs, it was like the backend, frontend and database, are not any different from each other at all. And so, the developing process becomes much painless. And this whole reason also answers the question why MERN stack, too. And while we are on this subject, Node + MongoDB + Mongoose is just a breeze. As their own WEBSITE quotes, Mongoose is an elegant MongoDB object modelling for Node.JS. And voila! This is why MERN.

So, that was backend in a nutshell. But for those who are just getting started with web-dev and mainly backend development, here is the roadmap to reach a position to build the backend for this exact website -

Road map to REST APIs : LEARNING MongoDB

The best place to start is by starting to learn and getting acquainted with a database. As whatever we are going to build, that is going to revolve around the structure of the database we choose to store and fetch out data form, one cannot go wrong starting off with learning the database.
Since in our case we are talking about MongoDB, a great resource to get started with is TUTORIALSPOINT-MONGODB.

Road map to REST APIs : LEARNING Node.JS

Now assuming that by now you are familiar with JS, (which if you are not, as I stated earlier can pick it up from W3SCHOOLS-JS), you can get started with Node.JS.
While vanilla Node.JS is not exactly what we generally use while building REST APIs, it's a good idea to know how Node.JS works without any other framework on top of it. A great resource to get started again will be W3SCHOOLS-NODE.JS.

Road map to REST APIs : LEARNING Express.JS with Mongoose for Node.JS with MongoDB

Like I said earlier, we generally do not use vanilla Node.JS for building REST APIs, and this is where Express.JS and Mongoose comes.
A great resource to get started with them is TUTORIALSPOINT-EXPRESS.JS

Road map to REST APIs : FOR PRODUCTION

While the above-mentioned resources are great to get started with backend development, to develop a backend which is actually going to be production-ready, there is a lot more to learn and understand.
And while building a backend, a very important and crucial aspect is making sure that the backend is scalable and can handle high traffic. So, it is my suggestion to take a professional course about "how to build production-ready & scalable backend".
There are a ton of options and ways how you can approach that, and probably one cannot go wrong with any of the options they opt for, but if I were to be asked to recommend a particular course to learn just that, I'll recommend NodeJS - The Complete Guide (incl. MVC, REST APIs, GraphQL).
And that's it, my friend, by now you are ready to build your very own Blogging Platform just like BLOGAROO

With this, I will conclude my blog about Developing a blogging platform using MERN stack.

Feel free to drop a comment below and react to this blog. I really hope this blog helped you envision a roadmap to how you can build a web application, complete with frontend and backend just like this one. Feel free to reach me out at my public email id. Thanks for reading.

P.S: All the resources that I have recommended here in this blog are completely of my own opinion. In no way I am related to them or have been sponsored by any. This blog is entirely based on my personal experience and the ways I went with when I was getting started.

BONUS

For those of you who are curious, here are the dependencies that went into developing BLOGAROO

(I have copied the list of dependencies directly from the package.json file for the following)

BACKEND

{
 //other stuff,

 "dependencies": {
  "@sendgrid/mail": "^7.1.1",
  "body-parser": "^1.19.0",
  "cookie-parser": "^1.4.5",
  "cors": "^2.8.5",
  "dotenv": "^8.2.0",
  "express": "^4.17.1",
  "express-jwt": "^5.3.3",
  "express-validator": "^6.4.1",
  "formidable": "^1.2.2",
  "google-auth-library": "^6.0.0",
  "jsonwebtoken": "^8.5.1",
  "lodash": "^4.17.15",
  "mongoose": "^5.9.12",
  "morgan": "^1.10.0",
  "shortid": "^2.2.15",
  "slugify": "^1.4.0",
  "string-strip-html": "^4.4.2",
  "swearjar-extended": "^0.2.0",
  "temporary-email-address-validator": "^1.0.3"
 }
}

FRONTEND

{
 //other stuff

 "dependencies": {
  "@material-ui/core": "^4.9.13",
  "@material-ui/lab": "^4.0.0-alpha.53",
  "babel-plugin-transform-remove-console": "^6.9.4",
  "bootstrap-material-design": "^4.1.1",
  "browser-image-compression": "^1.0.11",
  "isomorphic-fetch": "^2.2.1",
  "js-cookie": "^2.2.1",
  "jsonwebtoken": "^8.5.1",
  "moment": "^2.25.3",
  "next": "^9.3.6",
  "next-pwa": "^2.4.1",
  "password-validator": "^5.0.3",
  "prop-types": "^15.7.2",
  "query-string": "^6.12.1",
  "react": "16.13.1",
  "react-dom": "16.13.1",
  "react-google-login": "^5.1.20",
  "react-quill": "^1.3.5",
  "react-render-html": "^0.6.0",
  "react-sidebar": "^3.0.2",
  "react-web-share": "^1.0.5",
  "slugify": "^1.4.0"
 }
}

By Arunabh Arjun
www.arunabharjun.com

Developing an Ecommerce Web App using MERN stack — Arunabhstore App

Arunabh Arjun — Sun, 05 Jul 2020 14:54:05 +0000

Do you want to develop an Ecommerce Web App?

(Develop a web application complete with backend and frontend / Develop a full-stack web application / Develop a MERN stack website)

This blog will help you paint a picture, why to choose which tools while learning to develop an Ecommerce Web App.

In this blog, I will try to answer the reasons behind going with the options that I went with while developing ARUNABHSTORE. If you are a beginner developer, do give Blogaroo — Developing a blogging platform using MERN stack a read as I have discussed in details about the road map to learn a lot about MERN stack. As a bonus, that blog also discusses about Next.JS

So, let’s first talk about the actual Ecommerce Web App that we are going to refer to in this blog: arunabhstore.netlify.app/

What is Arunabhstore?

It is an e-commerce web-app built with MERN stack. I developed it just as a hobby. This is a completely functional web-app where one can visit, register, purchase and make a transaction with demo products. Needless to say that this web-app is only for demonstration purpose with all functionalities baked in and in working state. If you wish to experience this web-app, I encourage you to go ahead and make a demo purchase with the demo credit card provided in the checkout section in cart.

Technical Specs -

As the title says, I’ve built this using MERN stack, which means MONGO, EXPRESS, REACT & NODE

BACKEND

Node.JS with Express.JS
Mongo DB with Mongoose

FRONTEND
*React.JS

If you are interested, you can know more from GITHUB.

So, why React.JS

Before getting started with this project, I had done some work using React.JS for some small projects. So, I was very much familiar with the framework. I did consider other options like Angular & Vue, but I felt more comfortable with React.JS by that time. And what React.JS brings to the table is evident enough why one would want to go the React.JS route. It’s fast, easy to manage the states, and a lot more. So that is why React.JS. And frankly, I just really wanted to use React.JS 😅.

So that was my reason for going with React.JS for the frontend in a nutshell. If you are a beginner developer and most if it didn’t make sense to you, don’t worry. Just read the Road-Map in THIS BLOG. I have discussed in details how you could go from a complete beginner to a good front end developer, in fact, a full-stack MERN developer.

So that was all about the frontend part. Now you can be one of these two persons -

Start building the client app using React.JS and team up with a backend developer and hand over the backend part.
OR
You want to develop the backend yourself. If you the former, then it’s time for you to get started with developing your Web App. And I hope this blog helped you find the answers you were looking for. And I wish you very best of luck with your project. 😇 Now if you are later then follow along, I will explain why I went with Node.JS as the backend and MongoDB as the database.

So, why Node.JS?

If you have read THE OTHER BLOG that I mentioned earlier, then the answer is the same which I am simply going to go ahead and quote here -

For starters, it’s a JavaScript runtime environment. And being JS, there was not one-second thought for me. It had to be Node.JS. Moreover, with Express.JS which as stated in their very own WEBSITE, is a Fast, unopinionated, minimalist web framework for Node.JS. And as the frontend is also written using a JS framework, it would be very easy to build the REST APIs while being in the same paradigm of language, i.e. JS. Having said that, now I’ll answer the question to why I choose MongoDB.

Why MongoDB?

Just like I said for ‘why Node.JS?’, if you have read THE OTHER BLOG that I mentioned earlier, then the answer is the same which I am simply going to go ahead and again quote here -

The reason is very similar to “why Node.JS?”. MongoDB is a database that stores the data in the form of JSON (JavaScript Object Notation) like documents. And again, JS shines. As MongoDB stores data in an identical format to what we get as a response from REST APIs, it was like the backend, frontend and database, are not any different from each other at all. And so, the developing process becomes much painless. And this whole reason also answers the question why MERN stack, too. And while we are on this subject, Node + MongoDB + Mongoose is just a breeze. As their own WEBSITE quotes, Mongoose is an elegant MongoDB object modelling for Node.JS. And voila! This is why MERN.

Conclusion

What I would like to add here is that there is not anyone perfect reason or explanation to why you should use MERN stack, or in that matter, any stack. There are plenty of examples out there in the ocean of successful products that use completely different stacks. In this blog, I have discussed MERN as that is what I choose to proceed with after doing my research about different frameworks and their cons & pros. And frankly, I am very happy with the outcome what I got after finishing the project. And I sure do believe that whatever stack I would have chosen to proceed with, the outcome would have been very similar. What is important here is that whichever stack you are using, you should cover some really important points while developing the product. Some of them being scalability, agility, atomicity, responsiveness. While the backend should be as much lean & robust as possible and must be able to handle on-demand high traffic, the frontend must tell the users a story and at no point of the story, the user should feel like they are losing interest. And this holds for any web application, not just an Ecommerce App.

So this blog is more about building web applications in general and not specifically just an Ecommerce App. The reason I choose Ecommerce App to write this blog as that project was readily available at my disposal at the time of writing this blog. And everything that I have said completely holds for an Ecommerce App too. So there you go. I hope I was able to answer your questions and helped you decide as to what stack you can use while thinking of developing an E-commerce App, or as a matter of fact, most web-based applications.

Do go ahead and let me know in the comments what do you think about this blog. Feel free to reach out to me at my public mail id.

BONUS

For those of you who are curious, here are the dependencies that went into developing ARUNABHSTORE

(I have copied the list of dependencies directly from the package.json file for the following)

BACKEND

{
 // other stuff

 "dependencies": {
  "body-parser": "^1.19.0",
  "braintree": "^2.22.0",
  "cookie-parser": "^1.4.5",
  "cors": "^2.8.5",
  "dotenv": "^8.2.0",
  "express": "^4.17.1",
  "express-jwt": "^5.3.1",
  "express-validator": "^5.3.1",
  "formidable": "^1.2.2",
  "jsonwebtoken": "^8.5.1",
  "loadash": "^1.0.0",
  "mongoose": "^5.9.7",
  "morgan": "^1.10.0",
  "uuid": "^7.0.3"
 }
}

FRONTEND

{
 // other stuff

"dependencies": {
  "@testing-library/jest-dom": "^4.2.4",
  "@testing-library/react": "^9.5.0",
  "@testing-library/user-event": "^7.2.1",
  "bootstrap": "^4.4.1",
  "braintree-web-drop-in-react": "^1.1.1",
  "moment": "^2.24.0",
  "node-sass": "^4.13.1",
  "query-string": "^6.12.1",
  "react": "^16.13.1",
  "react-dom": "^16.13.1",
  "react-router-dom": "^5.1.2",
  "react-scripts": "3.4.1"
 }
}

By Arunabh Arjun
www.arunabharjun.com