JSS introduces the major difference to the way Sitecore projects are implemented: front-end developers take full ownership of front-end code. In comparison with the classic Sitecore project development approach, where your front-end code is mixed up and tight together with Razor views, in the JSS approach all your HTML, JS and CSS files are now isolated into a
Vue.js, etc. application.
How does this influence your Helix approach?
This blog post is an introduction and food for thought on the topic. In the nearest future I plan to implement a concrete sample on GitHub and write some in-depth blog posts about it.
Helix architecture and Sitecore JSS
To understand the impact, you should analyze the contents of each Helix layer and see how it can be mapped to the JSS way of doing things.
Normally in a Feature layer module you can find:
Classic approach: Sitecore Controller Renderings use MVC controllers to implement extra logic, for example, retrieval of Sitecore items, mapping\converting them to a view model to be used in a view.
JSS approach: front-end application communicates with Sitecore via the Layout Service API with no Razor rendering engine involved. Consequently, MVC controller is no longer required in-between to render a view. If you need to extend\customize the Layout Service output, you can implement custom Rendering Contents Resolvers or Layout Service context extensions .
Summary: you don’t need MVC controllers in your JSS solutions.
Most often you use API controllers to provide front-end with non-Sitecore related data, for example, data coming from your Business Domain. I see no changes here, however, I strongly recommend you considering to split out all Business APIs from Sitecore. You can find more details on this in my previous blog post .
.cshtmlRazor views are responsible for producing HTML for your Sitecore components.
JSS approach: front-end code is separated out and Razor views are not used anymore.
Summary: I see no reason in trying to squeeze in JSS app files into a Helix module. I strongly believe that front-end source code should live separately from Sitecore back-end related code.
However, it definitely makes sense to keep in sync the way front-end and back-end are split into features by maintaining the same naming conventions for the appropriate feature folders and components. This will make it easier for you to navigate through the source code and make sure front-end and back-end developers speak the same language.
Classic approach: Models in Sitecore projects are normally classes representing Sitecore items (typically mapped by an ORM). View models are used to pass data to views, typically combining Models with some extra data.
JSS approach: since there are no more controllers and views, you will likely not use models/view models very often, unless some complex Sitecore item structures need to be implemented in Layout Service API output.
Summary: Models will still remain, but will not be used as often as before.
Feature layer modules contain feature-specific configuration, for example: Sitecore settings, pipeline extensions, serialization configuration. I foresee no changes here, this is still relevant for JSS projects.
Services, Repositories, Infrastructure Code
Classic approach: typically, you can find examples of services and repositories abstracting Sitecore item API access and rarely performing some business logic.
JSS approach: as I’ve already mentioned, there will be less need in manual Sitecore items manipulation in your code, since most of the work is handled by the Layout Service API.
Summary: services and repositories will still remain, but mostly for business logic.
Typical Project layer modules contain:
.cshtmlRazor views representing project-specific layouts.
JSS approach: front-end code is separated out and Razor views are not used anymore.
Normally the Project layer contains configuration for Site definitions and serialization configuration (e.g Unicorn config files). Same will remain in JSS projects.
Front-end assets (fonts, js, styling, images)
Classic approach: In Project layer you normally store some project-specific markup overrides, for example, in the multi-site setup you might want the same Helix feature to have different look & feel, and Project layer is the right place for this.
JSS approach: you will store all front-end assets separately from Sitecore solution, consequently the Project layer won’t contain any front-end code.
When you think about a Foundation layer module in Helix architecture, you imagine:
Framework-type functionality, extensions, helpers which are shared across the solution. This will remain the same in JSS projects.
Classic approach: Shared front-end framework functionality, typically some extensions over existing frameworks, common CSS stylesheets, which can be re-used in features.
JSS approach: front-end app still needs to have some shared functionality to be reused across features, however, this code will not be stored within a Sitecore solution anymore.
Alright, so what’s the verdict?
These are the key takeaways:
Helix modules will contain less code, due to the fact that Sitecore JSS does a lot of item manipulation work for us. This decreases the value of keeping Helix modules in separate Visual Studio projects. And as you know, having a lot of projects in your VS solution increases build time significantly.
You should remember that in Helix architecture, it is the logical boundary and the proper dependency direction which matters, not the physical boundary (which is created by separate VS projects). Having many projects in a Visual Studio solution is often considered as an anti-pattern .
Therefore, you should consider combing your modules, especially in Feature and Project layers into a single Visual Studio project and enforcing Helix dependency principles in different ways . But, as usual, it depends.
Front-end developers will store their code separately from Sitecore back-end code, in some cases maybe even in separate source code repositories. However, even then it is important to keep in sync Helix feature names with an appropriate folder structure in the JSS application to make sure that code base is readable and easily maintainable.
Concrete setup will also depend on the fact if you have a multi-site solution, where you might want to share some functionality between sites.
Visually, this is how I imagine Helix architecture evolving in multi-site Sitecore JSS projects:
There are a couple of points to note:
- In case websites do not share any functionality, there is no benefit in the shared Feature layer.
- Front-end application code lives separately from back-end solution, either in a separate folder of the same source control repository or even in a different repository.
- Front-end apps internally should follow same naming conventions for Sitecore component\feature names, however, there is no benefit in forcing any Helix terminology\structure there. Give freedom to front-end developers, let them apply their best practices, do not enforce Helix.
What about Sitecore ORM frameworks?
It is quite common nowadays to use an ORM framework (GlassMapper, Synthesis, etc) in Sitecore projects instead of using Sitecore Item APIs directly. This brings a lot of benefits, such as abstraction and improved unit testability. After mapping Sitecore items to their strongly typed POCO representations, you typically pass them to the views, which transform the data into HTML markup.
However, JSS applications communicate with Sitecore via the Layout Service API. This API transforms page structure, including placeholders, components, and their datasources into JSON format. Front-end application then uses this JSON to build a page dynamically, effectively replacing MVC Razor rendering engine.
If Sitecore items are already transformed into their JSON representation, do we still need Sitecore ORM frameworks?
We do. But, referring to the discussion above about contents of a Helix module, much less then before:
- Sometimes, Sitecore component datasources are more complex than just one or more items with a bunch of fields. In these situations JSS Layout Service API won’t always be able to generate proper JSON output for front-end, hence custom code is required, which will process these complex item structures. And if this is the case, it is definitely beneficial to use an ORM tool.
- Besides Sitecore components, it is quite common to store some site configuration in the Sitecore item tree. These are typically some settings, which might need to be changed and “owned” by content authors or website administrators. Code using those configuration settings items can still benefit from using an ORM.
Not to mention, since JSS shifts focus on front-end, you should make sure that you have the proper capacity of front-end developers in your team.