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

8 min readJul 6, 2020

Are you a full stack developer & planning to develop your 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 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 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 the first impression lasts. And since likely, a person visiting your portfolio has not met you in person yet, the immediate activity is 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 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 models 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 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 a need to pre conceptualize the whole product with UI mock-ups, etc. And the reason why I 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, let’s 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, then who 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 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 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 are 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 many 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 😅. But what I am trying to convey here is that ultimately the two are going to be served from some kind of two different endpoints. 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, in 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)