4 min read web

0x008 - Jamstack 👾

0x008 - Jamstack 👾

Hi, y’all! Welcome to the eighth issue of unzip.dev, a newsletter dedicated to developer trends through unpacking trending dev concepts. My name is Agam More, and I’m a developer generalist. I’ll be posting every few weeks, so if you haven’t subscribed yet, go for it!

This issue took me some time as I just started a new journey as a digital nomad (I’m starting in Europe, and I will then probably head to the far east), So preparations took over my life for a bit!. Wish me luck :)

Jamstack

"J(Javascript) A(API) M(Markup)"

TL;DR:

  • Problem: Manually building fast, reliable, and easy-to-deploy websites is difficult.
  • Solution: Out-of-the-box CI, storing static files on a CDN, and using Javascript to create dynamic interactivity (all bundled through easy-to-use tools).
  • In Sum: Javascript, APIs, and Markup aren’t new, but combining them to create static sites offers a host of benefits that we can utilize.

How does it work? 💡

  1. The frontend is decoupled instead of using a templating engine on the server. Any additional javascript required can be sent and run on an as-needed basis, making browser reactivity inherently faster.
  2. Calls to an API (mostly serverless or micro-services), webhooks, or 3rd-party SaaS APIs for additional functionality.
  3. Markup (Markdown/HTML) static site generators compile static files which are stored in a CDN.
  4. Everything is version controlled. On each push to your main branch, the Jamstack provider will regenerate your site, invalidate the CDN cache, and deploy your site - including any backend changes (like changes in your serverless functions). Automated rollbacks will occur on failed deployments when your deployment fails without manual intervention.
  5. Headless CMSs are used to publish content via a UI, which are integrated with your frontend, without you having to maintain the server components for said content. This allows teams to include non-technical content contributors as well.

✨ The main idea is to utilize static files, CDNs, and scalable server-side (via serverless, 3rd-party APIs) and bundle it all together via great developer experience on specialized Jamstack hosting providers. Removing the burden of maintaining the hard parts of server-side operations.

Use cases ✅

  • Blogs are prime candidates for Jamstack.
  • SEO-critical applications.
  • Empowers non-technical users to control their frontend without code.
  • Full-stack engineers that want to focus on delivery.

Why? 🤔

  • Better DX: CI/CD via your version-controlled codebase connects seamlessly with all Jamstack deployment providers, making changes and deployment as smooth as can be. Plus, the frontend is decoupled from the backend - which means development can be done independently between the backend and frontend teams. Atomic deployments, automatic staging/production, and rollbacks which remove tedious and cumbersome operations.
  • Performance & Scalability: Static files on a CDN can be sent much more quickly to the browser. When you get a spike in traffic, the CDN handles most of the load. Coupled with serverless functions (which, by design, scale horizontally), you get out-of-the-box scalability.
  • Security: There is less server-side attack surface and most files are generated statically. A managed server-side is more secure than rolling and maintaining your own infrastructure.
  • Lower costs: Hosting static files is cheaper than rendering them on each request. Plus, having a free tier in most Jamstack-related players makes starting out very economical.

Why not? 🙅

  • New: There are only a few providers that position their offerings specifically for Jamstack projects. Vendor lock-in and missing eco-system solutions to your edge cases may be a problem.
  • Proliferation of needed tools: To mimic a traditional application, you might need to use a handful of 3rd-party SaaS providers. This can be hard to manage and maintain which can also incur significant downtime if one goes down. This could also impact costs, which should always be taken into account.
  • Managing moving parts: Having 3rd-party auth, search, forms, payments, etc… can seem like a hassle to manage (My personal opinion is that now you get to pick the best-of-class solutions instead of ad-hoc in-house solutions which you don’t want to reinvent the wheel for in any case).
  • Critical performance: A dedicated server with custom code might be the only solution for necessary high-performance needs (CPU/IO intensive server-side).

Tools & players 🛠️

🤠
My opinion: I really like the versatility of Next.js (and NextAuth), which goes hand-in-hand with Vercel or Netlify. For a DB, I’d use Supabase or Prisma + Hosted DB. I don’t have strong opinions on other tools at the moment, but don’t forget to look at the pricing before getting started with a service provider, as you won’t notice the financial impact until you pass the free trial.

Forecast 🧞

  • Market adoption: It seems like most web frameworks are going this way. I can see more and more individuals getting into web development starting with this type of architecture in mind. I can only see this idea growing even further. It could be the next LAMP stack.
  • More frameworks: You can already see Svelte (SvelteKit), Angular (Scully), and others creating their own version of Jamstack. I suspect to see more news ones, or at least an increase in the ecosystem of the top frameworks.

Who uses it? 🎡

Extra ✨

Additional related information that you should check out:

Thanks 🙏

I want to thank @TomGranot, the best DevRel I know and Tamir Kfir, one of the best developers I know - both helped tremendously with this issue.

EOF

If you are on nomadlist and are also traveling hit me up on the slack.

Any questions, feedback, or suggestions are welcome 🙏

Simply reply to this email or tweet at me @agammore - I promise to respond!

Agam More

Agam More