Enterspeed as the integration layer in Jamstack 🍓

Enterspeed represents the A in Jamstack. Our Speed Layer is the perfect match to your Jamstack architecture. The Jamstack architecture refers to JavaScript, APIs, and markup. The core principles of Jamstack are pre-rendering and decoupling.

The common theme for pre-rendering and decoupling is speed – speed and agility are both the DNA of Jamstack and Enterspeed. With Enterspeed, you can take your Jamstack websites to a new architectural level and reuse your website content across different frontend and apps.

When pre-rendering your website, you move all of the heavy liftings of generating the actual HTML pages out of the way from the end-users point of view. Not only does this provide a much-improved load time, but this technique also makes scaling your website easier.

Decoupling is about having a clear separation of your website layout and your business logic. With the Jamstack architecture, you delegate the responsibility for the business logic to the underlying API and leave the layout and user experience to the front-end layer.

Each API then has its area of responsibility – i.e. content, search, personalisation, or commerce. This provides more agility in the development process, allowing for each component to be exchanged individually.

The frontend as the de facto integration layer

With the Jamstack architecture, the frontend has become the de facto integration layer. This comes with both pros and cons.

Tightly integrating both the tools and people who are closest to the user experience makes a lot of sense. A team of skilled designers and frontend developers working with familiar JavaScript tools can deliver remarkable user experiences. However, from an IT architecture point of view, the frontend as an integration layer has its limitations.

What can happen when your frontend becomes the integration layer?

Integration code can be quite complex, and this causes two potential issues:

1. Lack of ability to reuse content
2. Lower performance and/or lower update frequency

Imagine that you want to add a native mobile app that reuses some content from your website. That’s exactly what the decoupled approach in the Jamstack is meant for. But your content is a mashup of your CMS content and PIM system data and the integration is done in your front-end code. The integration code in the front-end layer is not easy to reuse.

From the point of view of performance and update frequency, you can also become challenging. The integration of CMS and PIM data can consist of some rather complex rules.

For the sake of an example, let’s imagine that a full publish of the website is a 30-minute build job. For the website in this example that is not a real issue as a daily update is sufficient to keep the content fresh. But it’s not particularly possible to update a native app with the same interval. If the data has to be updated daily, then an API is needed.

If you have the frontend layer as the point of all integration, then the above native app scenario would result in both code duplication and lower performance and/or insufficient update frequency.

Enterspeed as the integration layer

Enterspeed’s low-code Schema definition language allows all kinds of developers to design and operate high-performing APIs for their frontend. With Enterspeed, you define what data you want available in your frontend, and from which of the connected sources it should come from. On every content update we receive from your source data, we update your data in Enterspeed to have it ready to be delivered in our high-performing Delivery API.

With Enterspeed, you get even more value from the Jamstack. By using the Enterspeed Speed Layer as the integration layer – and not your frontend code – you increase your level of decoupling between your different data sources, so you can use your frontend code to deliver an amazing customer experience.