Implementing projects with the JAMstack

Implementing projects with the JAMstack

We like to implement projects with the JAMstack. Read how we create modern, responsive and interactive cloud applications for web and mobile.

What is the JAMstack?

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.

The Javascript Client

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.

• Since these files are static, they can be cached so that the user's next visit doesn't require downloading the application again.

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.

• For security, the same (and usually more) validations are also performed server-side, and any validation errors are returned. Validation errors from the API are transformed to user-friendly errors client-side.

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.

The API Server

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.

The Markup

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.

Hybrid mobile apps

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.

Development speed

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.

Used technologies

Here is a list of tools, frameworks and other keywords we use for our JAMstack:

• Client-side: Javascript, Vue, Flow, SCSS.
• Server-side: Phoenix, Elixir, Ruby, Rails, NodeJS
• Markup and websites: Jekyll

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.

Resulting application

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.

Links

• Hybrid Mobile Apps: Providing a native experience with web technologies
• What is a hybrid mobile app
• JAMstack: Modern web development architecture based on client-side Javascript, reusable APIs, and prebuilt Markup

If you have any thoughts or questions, please get in touch with us via info@bonaroo.nl.