What's the recommendation for a new site/web application: SPA + BrXM or pure BrXM with JAVA components and Freemarker?

Experience Manager (PaaS/OnPrem)
1

Hi!

We are interested in finding out what’s Bloomreach’s suggested approach to implement a new web site using BrXM. Perhaps @woonsanko or @jeroen.hoffman could provide their valuable feedback on this one.

From the documentation there seem to be 2 main ways to proceed:

  1. Combine an SPA (Angular, React, Vue) for UI/UX with BrXM for contents and data sourcing.

  2. Use “pure” BrXM, with JAVA components and freemarker for UI/UX

Is there any other approach you would recommend?

Documentation pages don’t seem to favor or encourage one over the other, perhaps due to the objectives you would like to accomplish with the platform.

We are also wondering if a feature such as experience pages (where you can “build” a page from the experience manager by dragging and dropping components into the layout) and publish it (or schedule it for later) is also possible when the UI/UX is SPA-based?

The context for the site in question would be an e-commerce site primarily with additional sections for news and other types of informative data.

Thanks in advance for your kind assistance.
Juan

2

Hi Juan,
Experience pages are both supported for the SPA-approach and the Freemarker-approach.

Our own focus in development lies more on the SPA-side because we have an ongoing shift to moving the back-end to the cloud, exposing pages and content through REST APIs (our SaaS-offering).

From your side I’d say things depend on the functional want for a SPA-site, the availability of front-enders, and need for full separation between front-end and back-end (separate deployments can be beneficial).

HTH
Jeroen

1 Like
3

Thanks for the quick response Jeroen!

We are currently using experience pages a lot in our current site (freemarker-based) as it gives a lot of flexibility for new marketing campaigns as no new releases are required to create new pages.

We have created quite a few components to allow building pages with different behaviors and appearances (a few of them are shown below)

Screen Shot 2022-01-05 at 08.48.08
Screen Shot 2022-01-05 at 08.48.08300×1069 35.9 KB

Most of these components are configurable to use different contents kept in the CMS, parametrized to generate different searches and whatnot.

Is there any documentation on how would components like these work (and how they are implemented) in an SPA-based context?

We are very curious about how that works considering that the components catalog is defined in the CMS console but the actual components would reside in the SPA, in a different server (or at least that’s our understanding of it so far).

Kind Regards
Juan

4

Hi,
The overall idea is to have front-end components matching to the back-end components.

Front-end components consume (part of the) the Page Delivery API [1], back-end components may contribute to that API using #setModel method [2]. The SPA can be integrated in the Experience Manager using one of the SPA SDKs [3].

See also the whole Frontend Integration section in the menu of those pages…

Hope this helps!
Jeroen

[1] Introduction to the Delivery API - Bloomreach Experience Manager - The Fast and Flexible Headless CMS
[2] Model Contribution APIs - Bloomreach Experience Manager - The Fast and Flexible Headless CMS
[3] Bloomreach SPA Integration SDKs - Bloomreach Experience Manager - The Fast and Flexible Headless CMS