Hello,
I am trying to integrate the headless CMS solution in my application, but without the SPA implications. I would like to render the pages by myself using Apache Freemarker. I saw that you have available SDKs with Vue.js, React.js and Angular.
Is there any solution to simplify the response retrieved from the “/resourceapi” endpoint, to deserialize it somehow and further to allow me to set my attributes int .ftl files?
Thanks,
Bogdan
Hey Bogdan_Anton,
If you do not want to use the CMS in headless architecture and instead want to use Apache Freemarker, this is no longer headless. As such, it is unnecessary to use the Page Model API.
You can read documentation about Apache Freemarker support for the CMS here: HST Freemarker support - Bloomreach Experience Manager (PaaS/Self-Hosted) - The Fast and Flexible Headless CMS
Hello Nicholas_Pavao,
I want to handle myself the rendering step using Apache Freemarker in my Java application, move the ftls from Bloomreach to each application indiviually, or to have somewhere a repository for common components between various applications. At the moment, we have ftls rendered by Bloomreach and I would like to extract this functionality to one of Bloomreach consumers. I started by doing some tests to enable the “/resourceapi” endpoint and found out that the payload is pretty ugly and hard to manage. I saw that there are dedicated SDKs to handle to payload (for React.js you just have to pass the endpoint to “resourceapi” in a “BrPage” component and then to adapt the content. So the question is if there is any SDK for Java too, to make the payload parsing easier.
I hope it’s not stupid what I am asking here, I am pretty new in using Bloomreach, CMS generally. 
Dummy Architecture:
Browser ↔ Backend Application ↔ Bloomreach instance
Thanks,
Bogdan
Hey Bogdan_Anton,
We have a generic and framework-agnostic SDK for SPAs intended for frontend JavaScript frameworks.
Further, we have SDKs for React, Angular, and Vue. If you prefer to use Apache Freemarker, it is recommended that you use them integrated within the CMS project.
We do not have a Java-based SDK for this reason and if you wish to continue down this route, you will have to develop your own and potentially also develop your own API to work easily with it depending on your requirements.