What is FEaaS?
TODO: get the thread
james.gregory Feb 27th at 11:24 AM Aside from known nuances, any known concerns of using FEaaS and BYOC components in regards to the roadmap of upcoming releases? Are there any known (to the product team) upcoming breaking changes we should expect? About to lean into them heavily for a client having a good fit for them, but nervous framework may be altered in 6 months, causing rework. (edited)
9 replies
Eirini Feb 28th at 9:09 AM Hi @james.gregory , we are not planning to introduce any breaking changes so you FEaaS components can be used. But we do not recommend to use BYOC components
Marcel Gruber Friday at 9:59 AM You don't recommend using BYOC? Why not? Should the docs be updated to reflect that? https://doc.sitecore.com/xmc/en/developers/xm-cloud/bring-your-own-components.html#hybrid
james.gregory Friday at 10:04 AM Oh really? Can you expound why? It's a really great feature. Really useful for non-sitecore devs to define props and ui for them in the page builder. 10:07 Ideally I'd like a flow where a dev can write a react component locally, compile it, then publish to FEaaS. This would support richer component experiences needed by marketing teams. Looking at the Rest API as a way to do this, https://components.sitecorecloud.io/api/docs/static/index.html#/ (edited) Saved for later • Due in 22 hours
Eirini Wednesday at 6:42 AM Our Design Library is going to be built to visualize and create template-driven code components, and our strategy focuses on expanding and optimizing this component type. Aligning with these code components ensures a more seamless and scalable experience within XMC. That said, FEaaS components are a great tool for our Marketers, and no breaking changes are planned for them. In the long term, our low code builder will be merged with our AI coded component strategy. BYOC is an alternative, non template-driven code component and remains experimental, we would recommend to use the first two approaches.
georgechang :coffee: Wednesday at 1:58 PM I see BYOC as an alternative to regular SXA components - what’s the future of code-driven custom components? Is it still headless SXA? Should we ever favor BYOC over SXA components? 1:59 I can see FEaaS as a good alternative unless you have a strict design system (like a real one, not just colors and typography) then FEaaS only approximates adherence to the design system but may not fully conform. Saved for later • Due in 22 hours
Liz Nelson Wednesday at 4:58 PM FEaaS is an awesome feature and we totally recommend using it with exactly the caveats you mentioned George. With regards to "SXA" vs "BYOC", the major consideration in the choice for code based component patterns shifted for us because of AI. I agree the BYOC registration model is a lovely DevEx. We hope our new Design Library vastly improves the DevEx for non Sitecore devs to create template-based code components too. BYOC should definitely be used when you want to enrich a FEaaS component with some additional coded capabilities, but as Eirini was suggesting, we wouldn't recommend basing your coded component system on it. The background: The challenge with BYOC and many of our competitors who also have a runtime based code components, they aren't ideal for building brand-aware AI services. As Eirini alluded template-based code components means we have a database representation of the component, along with the code, which allows us to be much more powerful AI component generation tools, which is the future space we are headed -> FEaaS and code components blended in a single system where AI can do a lot of the work. :+1: 1
georgechang :coffee: Wednesday at 6:11 PM Thanks @Liz Nelson this was really informative! Are there more details around these template-based code components? I understand it’s probably relatively early days but interested to see how this new DevEx is shaping out. Also never too early to start thinking about migration paths. :joy:
