OCC Layer with a separated storefront like React or AngularJS

[#1]

Hi there,

I would like to st little discussion about topic described in the title.

Did somebody already made some experience with this kind of architecture?

What's are pros and cons of this architecture?

My Pros:

• easier to extend and maintain

• client-side rendering (higherperformance)

• the storefront is separated from the backend

• the storefront could be deployed separated

• the OCC layer could be reused from other platforms

My Cons:

• No hybris standard

• Hybris CMS doesn't work anymore (You have to build your own interfaces)

• What will happen if the framework will be not supported anymore

• Not many frontend developers are available at the moment

• possible Security Risks, because the code will be executed on the client

• possible Performance Issues on the OCC side

Many thanks for answers!

Greetz

[Former Member · Accepted solution]

Hi Dominik, I've seen client requests for this type of architecture (usually in topic of single page application) increasing recently and these are my observations and thoughts, specifically around single page application front ends (SPAs):

The people who typically champion SPAs are mobile developers who view everything as a mobile App. Usually javascript guys with no regard for business capabilities and NFRs for the platform as a whole.

Ecommerce sites are not applications, the whole reasoning for an SPA is the application part. Think Gmail. What they are not suitable for are content heavy sites which are logically assembled into pages.

SPAs are best suited where there is no concept of pages, where there is no SEO requirement and where there is no requirement for business user control over layout. You “can” “hack” SPAs into behaving like a traditional site, but then why would you do this?

SPAs will add a lot of cost and complexity to an OOB eCommerce deployment. To do it well, you are totally reliant on the APIs – these will be public facing, so I would advise you would porbably need an API broker (like Apigee) in front of hybris to provide monitoring, caching & CDN, security etc.

The mooted benefit of SPAs is control over presentation – this usually assumes this is a html / css developer tasks. If you have any desire for business user control apart from pure content (ie images / text in pre-defined slots), an SPA isn’t suitable.

[Former Member]

Hi Dominik,

I have used OCC with Backbone.js application. In Hybris 6.0, you have cms web service through which you can expose CMS related information. Prior to that, there were limitations in handling CMS contents.

You have rightly pointed out most of the pros and cons. With this model, you loose the flexibility of managing content lifecycle, a better customer experience etc. The CMS system like Hybris WCMS with storefront or Adobe AEM is more suitable for use cases where content plays an important role in the eCommerce landscape. With Javascripts kind of client in "Headless Commerce", the use case should be in a way that content management related functionalities are not of prime importance.

For security and performance issues, sometime API gateway are being used in between front-end and backend OCC layer in case you want to use as public API.

In OCC, you can manage caching at the server layer with Spring. You can also send Etag related information to client. So, some bit of performance can be managed though OCC layer. The version 6.0 of Hybris seems to be more matured in these aspects.