We like to implement projects with the JAMstack. Read how we create modern, responsive and interactive cloud applications for web and mobile.
According to jamstack.org, it’s a new way of building websites and apps that delivers better performance, higher security, lower cost of scaling, and a better developer experience.
The frontend is written in Javascript, running entirely on the client. This can be done with any frontend framework or library, or even vanilla Javascript.
All serverside processing and database transactions are abstracted into APIs, accessed over HTTP with Javascript. These can be custom-built or leverage third-party services.
Finally, templated Markup (usually static websites like bonaroo.nl) should be prebuilt before deploying.
We start with a client-side application written in web technologies and is compiled to static HTML, JS en CSS files. Whenever the user visits the URL for this application, the application is downloaded and executed. The application does not require downloading new assets to load other views.
Whenever the application actually requires user-data, it is loaded on-demand using APIs. The raw data provided by the API is transformed client-side for the user.
User-input is handled similarly: User-created data is transformed client-side to compact raw data and pushed to the API. The client is aware of common domain constraints and most validations can be performed even without a single API call.
Because rendering is done client-side without delay, the developer gets freedom to create highly interactive user-interfaces rarely seen in more conventional web applications.
Because this client-side application runs independent from all other components, it can be developed and tested efficiently and thoroughly. The client-side application scales perfectly.
Since the client-side application is fully static, all dynamic content is fetched from the server-side application through APIs. The server-side application responsible for reading and writing all data generated by users and from external sources. The server-side application is not concerned with the user or the interfaces presented to the user. It only pushes raw data around.
The server-side application is also responsible for authentication, authorisation and access control. It determines who can and cannot access any resource, and handles access violations accordingly.
The server-side application is finally responsible for communicating with other external servers, and for sending e-mails and push-notifications.
Because this server-side application runs independent from the user has no graphical interface, it is developed against a suite of tests. These tests are compact and execute in-memory, so we can write a lot of tests in little time, and execute them fast.
The result is a thoroughly tested and efficient server-side application that scales exceptionally well and is usually only limited by its database.
An application usually requires a dedicated website telling potential users about the application. Since the website is usually fully static, it can be generated at deployment. The result is a set of static files, just like the client-side application.
A static website can still be fully responsive, can still include analytics and can still include some dynamic elements. All dynamic elements are written in client-side Javascript, like the client-side application. Any server-side processing is done through APIs.
Load-times are exceptionally low, since no server-side processing is required. There is no page being generated on-the-fly. There is no server-side framework that can be abused or exploited. There is no processing required to render the pages, since all pages are already rendered at deployment.
Static websites scale perfectly, like the client-side application.
Native apps usually behave like the client-side application describe earlier. They are completely self-contained and fetch user-data from the server using APIs.
We like to bundle the client-side Javascript application in a native app. When the app is opened, the app renders the bundled static files, rendering the client-side application like a native app. This way, we don’t have to write dedicated native apps: This is called a Hybrid App.
While hybrid apps are written in web technologies, they have complete access to all native feature and component of any device. We only need to make small modifications in the client-side application to make them work on any mobile platform.
Well-written hybrid apps provide a near-native experience: It is very likely you have been using hybrid apps without realising it. Major examples include Yelp and Instagram.
Writing JAMstack applications can be done with similar development speed of conventional server-rendered web application. Modern client-side frameworks are essential to create a similar development speed.
Any potential overhead caused by writing abstractions in multiple separate code repositories to communicate from the client to the server is compensated by ease of development and testability both client-side and server-side.
Here is a list of tools, frameworks and other keywords we use for our JAMstack:
We also use sentry.io for error reporting on any native app, hybrid app, client-side application and server-side application.
Potential overhead cause by implementing some logic both server-side and client-side be reduced by sharing code between the client and server by writing both the server-side and client-side code in the same language: Javascript. However, we like to use Phoenix and Elixir on the server since we find it to be more reliable.
The final result is a thoroughly tested and exceptionally fast application that has very few potential scaling bottlenecks. It also include iOS and Android apps without exceptional development overhead, and the apps behave the same as the client-side application in the browser.
