JAMStack - JavaScript, APIs and Markup

2 min read ⋅ 45 views

Last week I came across this interesting term, JAMStack, while working on a prototype using Gatsby, NextJS and Netlify, all of which are uber cool and I'm planning to do write up on them in near future.

Although I have been using JavaScript for a long time, now more than ever, it’s difficult to keep up with everything.

What is a JAMStack

By definition, JAMStack is a modern web development architecture based on client-side JavaScript, reusable APIs, and pre-built Markup.

To simplify the definition further:

  • The front-end is built using JavaScript, obviously
  • All the interaction to back-end is done via APIs, whether it's for authentication, data or anything else.
  • Markups or templates are pre-built when we deploy the app. Although, if the first two points are achieved, then I think we do not strictly need pre-built markup. It can be with data or without data, as well.

What a JAMStack is not

As per the JAMStack definition:

"Applications which are tightly integrated with backend like Wordpress and Drupal"

This makes sense, when we talk about modern JavaScript based applications, we usually assume that front-end or UI is built in JavaScript and it uses the APIs to communicate with backend services. So any application which is in any way tightly integrated with the backend is not considered to be a JAMStack.

When I started programming, I only knew Java. So when anyone would asked what I did, I would say "I'm a Java Developer", whether I am writing JSP Pages, CORBA or EJBs. Nowadays with JavaScript, I need to explain which particular stack I use as well.

I have been using the MEAN stack for the past couple of years. Though everything is properly aligned using an Angular-based front-end, Node/Express back-end and all the interaction done via APIs, it’s still not considered a JAMStack app (but with some effort, it could become one).

So why the JAMStack approach?

The points mentioned below are from the original explanation, and I have added my two cents.

Performance

If you have a JavaScript-based front-end, you can load it from practically any CDN cluster. This will load your application blazingly fast, compared to single-source loading applications.

At AppGambit for newer applications, we're using S3 with Static Hosting.

Scalability

Because the front-end is just a bunch of static stateless resources, it can easily be replicated to multiple servers. This allows enables high availability for rendering. Although for the application to function seamlessly across a varying load, your back-end needs to be well designed. If the back-end is designed with a pure API based structure in mind, it is very possible to structure the back-end logic to serve the increasing load.

Security

I wouldn't say that JAMStack applications have any particular edge over regular applications when it comes to security. But I do agree that because the front-end is entirely separate, the API level security can be managed in a more separate way.

Developer Experience

This is true for targeted development. Just like it is for mobile application development; iOS development focuses on iOS specific things and Android development focuses on Android specific things. With a JAMStack approach, the front-end developer has more autonomy to structure the app, without any enforced structure from the back-end, and vice versa.

Because of the increasing amount of options available to build modern web applications, with clear separation we can achieve proper usability across both.

Conclusion

I think in a way, most newer web applications are built using this approach only. To serve different purposes like scalability, clear separation of concerns, using best-fit technologies, etc. With so many stacks already, it makes sense to take a step back and consider a proper approach to architecting them.

Resources

https://jamstack.org/

https://serverless.com/

https://nextjs.org/

https://www.gatsbyjs.org/

https://www.netlify.com/



JavaScript



MORE ARTICLES

Part 1: Building an API with GraphQL, Node and Express

We have been working on a mid-size application primarily using Express as an API Backend, and planning to migrate a port...

1155 views

Part 2: Building an API with GraphQL, Node and Express

This article is part 2 of 2 in a series. Make sure that you're familiar with Part 1: Building an API with GraphQL, Node ...

513 views

Part 1 - Building a serverless web app with AWS Amplify and Angular

In this article, we will be using the recently launched AWS Amplify service to build a serverless web application. At it...

225 views