JAMStack is an API-based alternative to WordPress and similar CMS. Its advantages are double-edged, but it is valuable for proofs-of-concept.

Client: ATNET

Year: 2018

Work: IA / Publishing system, Web application, Data management

Platform: JAMStack, MongoDB

What it is: API-based WordPress alternative with content management as a service separated from the front-facing website.

What it does: JAMStack publishing engines make for faster websites with lower hosting and maintenance costs.

How it works: The published website your readers see can be served from a static copy, similar to a snapshot, rather than dynamically upon request from a database (the WordPress way). Serving a snapshot makes the load time shorter and the navigation through the web app much smoother.

The Double-Edged Sword

Database systems are the bottleneck of security and maintenance costs.

With JAMStacks, one aspect of not serving through a database is that the security overhead is mostly outsourced to the provider of the content management API. The API will mostly come with a backend, a so-called BaaS (Backend-as-a-Service).

Understandably, there are attacks on these interfaces which can degrade the availability of your backend and also threaten your data.

Your website won’t be affected directly as you’re serving a snapshot which is always unaffected, but it is leaving you with not much to do in terms of mitigating any danger. You will never have as much control as you have with a self hosted solution.

However, it can be a great way to really slash the costs of a content-heavy publishing project that is meant to be a lean, inexpensive proof of concept, as long as confidentiality is not an issue: Static snapshots can be hosted for free or for next to nothing and some BaaS startups offer very generous free tiers.

To name one example, The Business Of Crypto runs on the combination of Jekyll static website generator, an API-based backend service with adjustable content model, VueJS and a MongoDB not exposed to the wilderness of public internet network.

In this particular project, data stored in the Mongo database do not need to be retrieved dynamically, therefore it is reasonable to simply hook a script to the Jekyll build & deploy routine that will export the current version of the data into a CSV file, which is natively processed by the Jekyll engine.

If the data stored in a database do not need to be retrieved dynamically, it is reasonable to only retrieve them once during the deploy routine and serve a snapshot.



Other Work