When working with Salesforce B2C Commerce Cloud in a hybrid approach (using SFRA with a Composable Storefront project), you naturally end up with some pages as SFRA Controllers and other parts of the project built on the Composable Storefront.
In that regard, you end up using SFRA Controllers, and it all works with the Composable Storefront through the magic of SLAS! But is the same true for using controllers to create REST endpoints?
There is a better native solution
Let’s get straight to the answer without beating around the bush: The answer to the question in this blog post is “NO.”
While controllers were the only option in the past, we now have a more flexible solution: Custom SCAPI endpoints that support all request methods (GET, POST, PUT, DELETE). This flexibility allows you to adapt to different request types.
Besides all request methods, we get:
So, if you have some controllers or custom OCAPI endpoints left over on a project built before this, it might be a good time to add a ticket to your backlog to upgrade them.
Are you still interested in the reason for this? If so, keep on reading!
Reasons not to do it
Supported methods
Out of the box, the only two methods you can support with SFRA are GET and POST. This is quite the limiting factor when working in a headless and composable fashion, where you make every endpoint a POST.
There is a way around this limitation that I experimented with before custom SCAPI endpoints were a thing in my “Headless Reference Architecture (Deprecated)”, a branch off of SFRA specifically made for Composable Storefront projects needing to create custom controller endpoints.
Personalisation and session bridging
When creating endpoints that require personalisation, you need to use “plugin_slas” to transfer your JWT to a session cookie. However, in specific scenarios, redirects and URL refreshes are some of the “actions” that occur.
While this is fine for a regular user loading a page in the browser, for integrations, it can be a significant hurdle to overcome.
It can also introduce extra API calls and delays in getting responses.
Adding complexity to your API architecture
Employing session transformation and SLAS this way increases architectural complexity, complicating debugging efforts unnecessarily.
Session creation
One of the benefits of choosing Salesforce is that we don’t have to worry about server and hardware-related issues, as scaling happens automatically. However, this doesn’t mean we should introduce unnecessary load onto the system just because we can.
A downside of calling a “controller API” is that it behaves like an SFRA request. If the request does not attach a session cookie, the system will recognise that it needs to start a new one.
If we poorly implement a custom endpoint that is called on every page load to retrieve “mundane information,” we will create thousands of sessions for no reason. These unnecessary sessions also need to be cleaned from the database, creating additional system load that could be better utilised.
Conclusion?
The conclusion was already shared at the start of the article!
