MY PREFERRED TECH STACK

In the software development world, there are many different tech stacks which all serve a different purpose. Today I'm going to detail what tech stack I prefer to use and why. Remember, this is just my personal preference and people are welcome to use the stacks that they like.

As I mostly work on web-based projects, I'll be splitting this article into two parts. One part to cover websites and the other part to cover web apps. I'll also provide a short version directly below for those that just want a quick summary of the stack I use.

Summary

For static websites I use:

• Next.JS/React for the frontend
• Sanity.io for the headless CMS

For web apps I use:

• Next.JS/React for the frontend
• Node.JS as the backend language
• PostgreSQL or MongoDB (for the database)
• GraphQL endpoints for the API

Website Stack

Sometimes you just want to create a static website. Some examples of this could be this blog, a business or personal website. For this type of project, my. preferred stack for this is Jamstack. Jamstack describes itself as:

"Jamstack is an architectural approach that decouples the web experience layer from data and business logic, improving flexibility, scalability, performance, and maintainability"

So the way I use this type of stack is using a frontend framework to generate the UI combined with a headless CMS to provide the content.

Frontend Framework

My go-to frontend framework is Next.JS. I prefer to use Next.JS as it provides a lot of tools out of the box such as Image Optimisations, Pre-fetching and Routing.

Find out more about Next.JS here.

Headless CMS

There are many headless CMS platforms out there and many more emerging on to the market. My go-to CMS that i'm currently using is Sanity.io. The reason I've chosen Sanity is their developer-first approach where your content is defined in schema's through code which allows for a lot of flexibility. I am a big fan of infrastructure-as-code so this works well for me. They also have a generous free plan for their cloud hosting.

Find out more about Sanity.io here.

By utilising those two tools, I can quite effectively create a powerful static website. Read on to the next section where I took about my preferred stack for creating web apps.

Web Apps

I define a web app as an application that runs on the web. Something that is logic-driven and provides a purpose more than just presenting some information to a user.

I prefer a decoupled approach where the frontend and backend systems are kept separate. There are a few benefits for this and are as follows:

• Separation of Concern -> The frontend only cares about presenting data to the user and the backend only cares about the logic of that data.
• Security -> By keeping both separate, if one is compromised the other one may still be safe giving you slightly less of a headache.

Frontend Stack

To no surprise my go to framework for the frontend is Next.JS. The amount of tooling for this makes it really easy to get started on your web app's UI.

Backend Stack

The core of my backends are typically coded in Node.JS. By using Node.JS, my code base remains purely in Javascript as opposed to something like PHP where the whole project is integrated with HTML, JS and PHP code. Node.JS also has a ton of support and performs well for the use cases I need it for.

Find out more about Node.JS here.

Web Framework

By going with Node, you'll also need a web framework which my go-to for this Express as it's really easy to deal with and get started.

Find out more about Express here.

Database

My choice of database is dependent on my project's needs. If my data was heavily inter-connected and needed strict structure, I go with PostgreSQL to allow me to query my data more efficiently. If I just needed a loose data structure where I was just storing collections of data, I'd go with MongoDB as that allows me to retrieve simple data easily in a JSON-like structure.

Find out more about PostgreSQL here.

Find out more about MongoDB here.

API Architecture

There two most common types of API architectures with modern apps are REST and GraphQL. REST API's utilse the HTTP protocol to send and retrieve data through endpoints whereas GraphQL is more of a query language for your data.

I prefer to use GraphQL for my projects as I can employ a Backend-For-Frontend approach where my frontend can describe what data it needs which allows for faster performance as it doesn't need to retrieve an entire row of data if doesn't need it.

Find out more about GraphQL here.

The implementation for GraphQL I prefer to use is Apollo.

Find out more about Apollo here.

Thanks for making it this far. I hope that you were interested in the tech stack that I use and maybe have learned something new.

Thanks for reading,
Kaleb Cooper