General | Headless Development | Oryx

schoenfeld

I am interessted in your point of view or maybe you have answered them already in context of the new ORYX framework.

I always think the FE should be "stupid" as possible, and all logic should be integrated into GLUE API.

And this automatically answers me these questions:

- caching? ⇒ Spryker Redis (used by GLUE), not a new one
- translations? → Spryker Redis, new feature in GLUE to return them and store them in localstorage (etag)
- routing/url-resolving (+redirects)? ⇒ spryker url-resolver
- dynamic form fields in checkout based on customers cart? ⇒ new feature in GLUE
- step validation in frontend? ⇒ use GLUE checkout-data endpoint
- CMS Integration? → extend or use existing content feature in GLUE to support this CMS
- etc.

What do you think?

Because in our current project, where we have integrated the GLUE in a nuxt3 application - its a big issue. A FE Dev is building in solutions, that are already solved in backend. But i think much as possible GLUE API solutions should be integrated, to make it easier in FE to build things and to leave the option to extract it into their own spryker packages. Thats what the layered architecture is good at.

But ofc its depending on project requirements to define whats more important:
- decouple FE from Spryker? (they always ask for it, but i wonder why they have bought spryker if they plan to replace it again)
- decouple Spryker from customers business logic? (integrating more and more third party services into spryker backend to reduce development work there).

Since composable FE is a spryker FE, i think it can be used to build up new functionalities for GLUE (+ backoffice) and force a rounded package with BE and FE solutions for a PaaS customer. Without a too strict separation (i.e. translations only in FE, Routing only in FE, request caching only in FE…) of things and too heavy bloated business logics (i.e. validations, customer role checks, net/gross price permissions etc.).

What do you think regarding this six architecture examples at the top, how they should be solved in Composable FE?

Tobias Ouwejan

Thanks a lot for the questions. It's a lot to answer, and hope it's helpful to reply. Let's see, if not, we can break it down in smaller pieces to see how we can help you best.

> I always think the FE should be "stupid" as possible, and all logic should be integrated into GLUE API.

I don't necessarily agree to this statement, but it's for sure a strategy to use if you like it. In omni-commerce, ecommerce platforms tend to serve multiple users, business models and touch points, which is one of the reasons why I'd be careful to make tightly coupled "backend for frontend" API. Moreover, over time, when the business and the experience layers like to evolve, too much coupling might block future enhancements. I'd therefor go for a headless backend, and see it as a separate product/project that evolves at its own pace, using its own architecture and design.

Stupid FE could work to a certain extend. The example of routing is good, I'm all to avoid hardcoded routes in the FE so that can be business driven/runtime configurable rather than hardcoded. A combination of both is also fine. In Oryx, we use "semantic links", which are configurable (not yet by a BE though), which are connected to static functional pages, such as login, pdp, plp, cart, etc. At the same time, Oryx integrates with headless CMS solutions where the page slug is resolved from the content.

> caching? ⇒ Spryker Redis (used by GLUE), not a new oneNot sure if I understand the context here. Oryx will not use Redis. BE APIs might, but it's transparent for Oryx/FE. Oryx would benefit a whole lot from CDN, for sure for static resources (application and content), but even for API responses API responses could work really well. Additionally, there's the browser layer to benefit from cache, both in memory and caching the responses in service worker or standard cache control.

> translations? → Spryker Redis, new feature in GLUE to return them and store them in localstorage (etag)we'd like to have a translation API on the platform. The response could - again - be cached on CDN -> browser. I don't see a place for local storage. ETag could be used, but I'd rather use expiration headers as this will save the round trip to the origin server.

> routing/url-resolving (+redirects)? ⇒ spryker url-resolverI'd not resolve routing in the platform, unless we have a dedicated "experience" application that is build to manage those _semantic links_ that I mentioned before.

> step validation in frontend? ⇒ use GLUE checkout-data endpointI do not like this one. This comes back to the first statement I made; decoupling the FE from the API gives more flexible to create the right experience for the user/business/time/etc. The checkout flow could be driven by the actual items in cart, rather than a static journey.

> CMS Integration? → extend or use existing content feature in GLUE to support this CMSWe have a labs package that contains 2 integrations with headless CMS. This demonstrates nicely how we can integrate with any CMS going forward (only need to write an additional Adapter for the CMS of choice). With this solution we have integrated multiple CMS's in parallel, get search results in the global search box as well as configure individual search boxes for single CMS (e.g. search box on FAQ page). Moreover, we are able to render oryx components inside the content coming from CMS.

> decouple FE from Spryker? (they always ask for it, but i wonder why they have bought spryker if they plan to replace it again)The composable nature of the composable storefront is driven partially because of the decoupled architecture. Other important considerations are agility (change FE without BE involvement), break the monolith, scalability, performance, experience, etc. Decoupling is coming and going. It's definitely the only architecture to consider. Some of the modern (js) frameworks start to go back to coupled architectures or a mixture. It's not our direction though.

> decouple Spryker from customers business logic? (integrating more and more third party services into spryker backend to reduce development work there).We acknowledge both architectures; both come with PROs and CONs. Some integrations go straight into FE, others are behind GLUE APIs.

Cheers tobi