What is the Storefront Reference Architecture and Why Should You Use It?
If you’re using the Salesforce Commerce Cloud platform then we’re sure you’ve heard about the Storefront Reference Architecture (SFRA) by now. SFRA is a relatively new architecture for the platform that was released last year in an effort to improve the user experience, specifically for mobile users. With mobile users constituting more and more site traffic, it’s prime time to consider upgrading to the new architecture, which aims to improve the mobile online shopping experience. Some of the biggest changes with SFRA are the mobile-first design philosophy, flexibility and maintainability of the code base, and the general improvements to UX and load speeds.
SFRA Puts Mobile First and Streamlines Checkout
Fun fact: SFRA was originally referred to as the Mobile-First Reference Architecture (MFRA) due to its mobile-first design. This ended up causing a lot of confusion around whether or not it was a mobile-only design, and eventually led to the name change right before its general release. The mobile-first design practice is simply developing your site from a mobile perspective first and then working your way up and expanding the designs to desktop.
One of the first big changes with SFRA is that the templates now utilize bootstrap out of the box. The base templates are now fully responsive and provide a much better user experience for mobile users. This makes it much easier to maintain a mobile-friendly site since most of the heavy lifting has already been done. Additionally, the checkout process has been streamlined into a single-page experience with accordions for each form section, which expands and contracts as the user moves through the process.
This is a huge improvement over the site genesis checkout process, which required full-page refreshes for each step of the process. The original checkout process could be especially painful on a mobile device where load times tend to be much worse. Another positive side effect of the new checkout process is that fewer clicks are needed to complete your checkout, which should lead to fewer abandoned carts.
SFRA Improves the Flexibility and Maintainability of Your Code Base
Probably the biggest change to SFRA is the new controller structure. Salesforce knows that the out of the box codebase doesn’t support everyone’s needs and that everyone will be doing their own unique customizations. In order to better support these customizations, controllers have been revamped with extensibility in mind through the concept of the middleware chain and the ability to append or prepend functionality onto the base routes. Instead of just having one block of code that runs when you hit an endpoint, it will now call a series of middleware functions, each handling their own bits of logic and functionality which makes it much easier to customize the out of the box functionality and allows you to create reusable pieces of code that you can easily drop into other routes.
For example: when looking at the Account-Show route, we want to use HTTPS and make sure the user is logged in before showing the ‘My Account’ page. Both of those steps are general pieces of functionality that could be useful in other parts of your site. With SFRA, they have been extracted into middleware functions that can easily be tacked on to whatever endpoints you like.
SFRA Makes it Easier to Add Custom Functionality
Furthermore, with the concept of extending the main function of a route, you can easily alter the functionality of the base endpoints without having to rewrite or duplicate code. Instead, you can simply extend the main function to prepend or append your custom functionality, depending on whether you want it to happen before or after the base code runs. There is also an option to completely replace the route but you should try to avoid doing this whenever possible, as it can interfere with other cartridges trying to append functionality. You can also set up event listeners for events such as a route first starting or a route finishing the middleware chain if you want even more control over the flow. One of the most important aspects of this is that all of your custom changes are made in a separate cartridge, so the base code is never touched. This makes it much easier to add or remove custom features as business requirements change, and also aids in keeping the base code maintainable and easy to upgrade.
Final Notes on the Middleware Chain and Code Maintainability
Regarding the maintainability of the code, both the middleware chain and the extension functionality offer their own benefits. With the middleware chain, if you ever need to update the functionality of a middleware function, you simply make the change in one place and it gets applied to all endpoints making use of it. As for extensibility, this makes it easy to add and remove functionality as business requirements change simply by updating the cartridge path to add or remove the cartridges providing that functionality.
Also, if you ever want to upgrade the base SFRA code to a newer version, your custom code is in a separate cartridge so it won’t be altered in any way. Finally, you can easily see what’s changing between the versions so you can validate any customizations that might be affected. These changes make it easier for developers to implement new features or pull in the latest functionality from Salesforce. That ease of use translates to a faster time to market and overall lower project costs.
SFRA General Improvements
SFRA also introduces several minor changes that are worth mentioning. The most important is probably the UX updates to the base templates. Salesforce has done thousands of site audits to analyze how the UX affects site performance. Using this data, they have assembled a list of UX best practices for small tweaks that can help improve conversion rates. Most of these improvements can now be found in the stock SFRA templates, which means you will likely see a lift in conversions after making the switch to SFRA.
Another useful change is with the models. Object models were added in the Site Genesis JavaScript Controller (SGJC) architecture as a way to better support the MVC pattern. All of your business logic would be handled in the controllers and all the data you need to render a page would be passed to the front end through object models. With SGJC, these models were basically a wrapper for the system objects, which meant you were passing quite a lot of unnecessary data to the front end. SFRA has updated these models to only pass the specific pieces of information needed for a page instead of the entire system objects. This does mean there’s a little bit more overhead in updating views since you will also need to update the models, but the result is quicker page loads, as there is less data being passed around
The last note I want to make about SFRA improvement is the added support for unit testing. SFRA now comes with unit tests for much of the base functionality. These run on Mocha and can be triggered from Node by using ‘npm test’. This makes it easy to integrate the tests with your continuous integration / continuous deployment pipelines. This can help ensure code quality by testing critical site functions as part of the build processes and making sure the new code isn’t breaking anything.
Making the Full Switch to SFRA Eliminates Development Headaches
So, if you’ve decided that it’s worth making the switch to SFRA, the next question would be how to go about pulling it off. As with SGJC, it’s technically possible to mix and match the different architectures as long as they’re in separate cartridges. That being said, I would highly recommend against going that route and instead, trying to convert the entire site in one go. Doing so ensures a consistent experience across your site and serves as a great chance to clean up tech debt. Trying to swap to SFRA piecemeal adds a lot of overhead to the development process by having to rip apart existing cartridges to remove certain parts of functionality that are being replaced by SFRA.
It will also require much more QA time to make sure everything is working as expected between the different architectures. In addition to these issues, it’s also more of a pain from a development standpoint to need to follow different coding styles depending on which part of the site you’re working through. You will definitely save yourself plenty of headaches if you make the full switch all at once.
Have more questions, or want to learn more about Salesforce Commerce Cloud SFRA? Our talented, Salesforce certified developers are here to help, and create a seamless Ecommerce experience for you and your brand. Contact us today at info@cqlcorp.com or by clicking the button below.
