:format(webp)){kind=small}
:format(webp))
JAMStack?
JAMstack refers to an architectural approach leveraging Javascript, Apis and Markup, that uses prebuilt pages delivered via a CDN, with JavaScript and APIs for dynamic features. Some apps also need server-side services.
So what’s so good with JAMStack?
Fast delivery of prebuilt pages
Crawlable pre-rendered content
A smaller attack surface for static pages
No application server needed to serve prebuilt pages
CDN delivery helps handle demand for static pages
Low-cost deployments are possible
LOFTY CLAIMS! How is this achieved?
A static site is mostly just a bunch of html files and images. You can just copy them up on any CDN and have a new version live.
Build markup with a Static Site Generator, deliver with a CDN, and use JS + APIs for dynamic parts.
A CDN can serve prebuilt pages without an application server handling each page request. That can reduce the infrastructure needed for those pages, but APIs and functions still need security controls and capacity planning. Pre-rendered HTML can make core content accessible to crawlers without client-side rendering; performance and search visibility still depend on the implementation.
Our content managers don't do html.
There are numerous ways you can let content managers create new content. You can use a headless CMS like Contentful or Prismic, or even Wordpress. In your build process you pull content from your CMS and pre-generate html pages. Most headless Content Management Systems support webhooks, so you can trigger a re-build of your site and have it re-deployed to the CDN when someone publishes new content. For your developer-types you can have a git based workflow with markdown.
This is so 90s and we need modern UX. Can’t I have my React?
Enter GatsbyJS. You can have your cake and eat it too. It’ll pre-generate html files based on your React components, and re-hydrate your app as a fully fledged React app once the page has loaded.
Fine for sites, but what about APPS? We need data and custom apis.
A lot of the backend functionality implemented in every project is re-inventing the wheel over and over again. Consider consuming some pre-existing services instead of adding more backend maintenance and ops work to your plate ad infinitum.
For example:
Many of these can be integrated with pure frontend integrations. If you do need something custom, consider a serverless lambda/cloud function and outsource the tedious and costly ops and scaling part of backends.
For a concrete example, see our 2020 KitaExpert JAMStack app: it combines a Gatsby frontend with scheduled lambda functions to refresh its data. This is a project example, not a default stack recommendation for new apps.
For another approach to data and APIs, watch our Hasura video on an alternative to the conventional database, backend and API combination.
That just leaves us a bunch of frontend work.
Yep. If you ask me, Frontend is the new king (with some help from serverless offerings).
If you really want, you can still use your own hosted backends too. Just because part of your app ecosystem is JAMStacked and serverless doesn't exclude custom backends if that's the path of least resistance for you. If static files don't fit for a portion of your frontend app, you can opt not to have that specific part of your app/site pre-generated as static files (Gatsby has you covered).
If you ask me, Frontend is the new king.
Minimizing your backend footprint with serverless options can simplify product iteration by letting you deliver frontend changes independently. A staging version for each commit can make reviews easier, though hosting, builds and serverless usage may incur costs.
A CDN can help handle changing demand for static pages, but provider quotas and usage-based costs still matter.
For a broader look at migration, accessibility and edge computing, read our Jamstack website guide.
:format(webp))
:format(webp))
:format(webp))