So why go JAMStack?

iordacheandrei profile image iordache-andrei ・3 min read

Hello dev.to,

I've recently discovered this community and with a few interesting discussions and guides around here, I've decided to do my "Hello World" post with a multi-part question:

Why should I choose a JAMStack approach?

Let me preface this that I may have a very bad approach of understanding the benefits, or that maybe my concerns of applying the stack may be completely derailed by how I usually work or am requested to work. That being said... instead of writing down my (and what could be completely unfounded) opinions about it, I decided to ask more targeted questions in relation to what I found on what JAMStack would be used for.

Why is security emphasized?

This ties a bit into pricing but for the sake of not nitpicking this to the end of time let's ignore price.

To expand a bit: Yes, using an already hosted database/backend server with a built in, or have the ability to throw one in, headless cms (strapio, netlify, wordpress, drupal, shipcart and so on) does give an impressive reduction in issues related to functionality, security, uptime, troubleshooting and other related problems that can appear. Don't get me wrong, I have some huge respect for the devs that make some of that magic work so magically, but using a service like that is never the end-all answer, in fact quite a lot of the clients I've met demanded more in-house solutions to the data they stored, regardless of the sensibility of it.


This is particularly questionable due to the original goal and the end point of the project. Due to obvious reasons, static generated webpages are not dynamic in nature, so adding functionalities later on like a e-commerce base or a user management with custom content based on user (or whatever else you want to load on whatever condition) is either a impressive chore or straight up a complete dump and rethink the project.
I guess the question would be: Other than in throwing more pages, what's the actual scalability?

What is practicality of it?.

This will be a bit longer since it ties into more of the details!

Having a decoupled front-end from the back-end is not something specific to static websites in itself, nor is having them hosted on different servers. That aside, I do understand the ease of use with SSG's but that's about where it stops for me. Webpage speeds are also reliant on server/api response, response size, locations, etc; Monoliths haven't been specifically a issue since JS frameworks have been around and depending on the client requests or company decisions monolithic architectures are not gonna die soon either.

Up till now, the only real justification of JAMStack is that it's very handy for micro to small projects like presentation websites, landing pages, demo-ing, etc.

The things I like!

There are a few things that I like about this concept.

  1. As said before, very handy for micro to small projects that do not require any specific investment. I am leaning to create a new portfolio website for me using Nuxt or Gridsome with firebase as a quick deploy cms. I may not particularly use a CDN for the client website itself but that's something I will decide when I get the thing started.

  2. Atomic Deployment and Instant Cache Invalidation. Not gonna lie, I might try to cook up a method to implement a system like this in my existing and new projects as it can save me a few hours of headaches.

  3. Granular control. This is something I appreciate on projects that I am not hamstrung to a tech/stack that I don't enjoy or consider to be inappropriate for the purpose of the task.

All of this said, I do hope to get a bit of enlightenment on JAMStack itself and I hope I wasn't too bipolar of the concept. For me it boils down to it being more of a novelty rather than a real-world use.


markdown guide