To JSS or not to JSS

-

Sitecore JavaScript Services (JSS) was launched, now a few years back, as Sitecore's solution for meeting the needs of doing headless content mangement on Sitecore using JavaScript, without losing the key capabilities (especially in line editing) which makes Sitecore great. It consisted of JavaScript SDKs that worked with the JSS layout service running on Sitecore. Now renamed the Sitecore JavaScript Rendering SDK, and supporting the JSS services or Experience Edge, this SDK is an important part of delivering JavaScript web apps leveraging Sitecore editing capabilties.

That said, for a lot of front end developers JSS is a skillset that they might not know a lot about. Using it properly requires not only an understanding of how to install and work with the SDKs, but also understand Sitecore concepts such as placeholders. Furthermore not all web use cases, even those that leverage content, benefit from such advanced capabilities.

Benefits and complexities

I see the following pros and cons of using the JavaScript Rendering SDK

  • Benefits
    • Enables Sitecore inline editing tools (Experience Editor/Pages)
    • Supports page composition directly by business usets through support of contetnt placeholders
    • Supports consistent routing to pages based on Sitecore items
  • Complexities
    • Another library and additional concepts for front end developers to understand
    • Not all sites, and not all parts of some sites, benefit from the page composition and inline capabilities offered by enterprise CMS
    • Sometimes not all URL routes in a complex headless app are driven by data/content in Sitecore

Micro front ends and a trade-off

Larger headless solutions in the enterprise will usually benefit from taking a micro-frontends approach to building out the "head". This breaks down the head into a number of sub-components, each usually worked on by different teams. It breaks down what could otherwise become a new monolithic custom application into smaller parts.

The trade off that we have taken in projects for JSS, especially where Sitecore is one component driving the web experience, is to leverage this pattern and only use the Sitecore JavaScript Rendering SDK in those apps which are content centric. This could be apps the drive general content pages, landing pages, articles pages or even the homepage. However other parts of the site such as product detail pages, shopping cart or checkout don't include the JSS SDKs.

Those pages leveraging the JavaScript Rendering SDKs leverage the "JSS" services (layout service for traditional sites, or the GraphQL endpoints for Experience Edge) directly from the SDK. Any pages that aren't driven by the SDK but that still need content leverage the BFF service, which themselves use the Sitecore APIs (REST or GraphQL) to source content, and return it along with data in the call used by the front end. This means that developers of those apps treat content no different to any other data used on the page. They don't need to consider concepts like placehodlers, but need to manage all page layouts as a part of the application (and all changes to e.g. ordering of any modules require developers to change.

Comments

Post a Comment

Popular posts from this blog

Cloud hosting Sitecore - High Availability

-
Image
The approach to hosting web facing systems has changed significantly over the last few years, with virtual machines almost completely replacing physical infrastructure.  These private cloud virtual server farms allowed server instances to be built and run on consolidated hardware, simplifying purchasing for IT departments.  This cloud computing pattern is generally known as Infrastructure as a Service (IaaS), and it simplified the way that physical hardware was purchased, whilst supporting the same approach to building and deploying applications that had been used before.  Public cloud hosted IaaS platforms remove the purchasing requirements, whilst providing a high degree of flexibility in how services are hosted, however IT teams still had to install and configure operating systems and other system software like content management and database systems the same way as with traditional environments.   Amazon Web Services and Microsoft Azure are currently the two leading IaaS cloud
Read more

Setting up TDS to work with Azure DevOps

-
Image
We recently had the challenge of moving across a legacy project, that we inherited, to run on Azure DevOps.  This project is five or six years old and still leverages TDS for packaging Sitecore items. Helpfully the code repository already had a copy of the nuget package contents checked in and referred to by the TDS project files, however this was designed to use an older version of visual studio (2015) than we had available as a part of the default Microsoft supplied build agent (2019).  In addition we needed to make sure the build agent was able to use our TDS license keys. Setting up the TDS license The old HedgeHog documentation has some good info on how to set up TDS to run on a build server.  This states to set up two environment variables: TDS_Owner and TDS_Key with the license information that the TDS tool will look for at runtime. Our first attempt to follow this instruction for DevOps was to create a powershell task to set the variables - task: PowerShell@2 displayName:
Read more

Sitecore - multi-site or multi-instance?

-
Image
I have been asked by a number of different people recently about when it is appropriate to maintain a number of different websites on a single Sitecore instance, versus deploying multiple Sitecore instances (on the same or separate hardware) to keep sites separate. As is usually the case, the answer is "it depends", but there are some key conditions that can lead to a clear choice between one over the other. Single Instance In the single instance approach, there is a single installation of Sitecore that hosts all of an organisations sites. This means that there is one IIS website hosting Sitecore per server all sharing the same Sitecore configuration and content. Pros Single set of user access credentials for access to all sites If you are not using LDAP integration for login to your Sitecore instance (or using some other customisation such as federated security through something like ADFS), having a single instance lets you use the same set of Sitec
Read more