Enterspeed as the integration layer in Jamstack
When pre-rendering your website, you move all of the heavy lifting 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 front-end as the de facto integration layer
With the Jamstack architecture, the front-end has become the de facto integration layer. This comes with both pros and cons.
What can happen when your front-end becomes the integration layer?
Integration code can be quite complex, and this causes two potential issues:
- Lack of ability to reuse content
- 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 challenged. 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 front-end 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 front-end, 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. With using the Enterspeed Headless Hub as the integration layer – and not your front-end code – you increase your level of decoupling between your different data sources, so you can use your front-end code to deliver an amazing customer experience.