While there was a lot of exciting news and tech showed at this year’s Sitecore Symposium, perhaps the biggest takeaway was the release of Sitecore Javascript Services. Known as JSS, the new SDK was one of the big focuses of this year’s symposium. I arrived in Orlando wanting to know how this new SDK would allow Sitecore to utilize headless principles and Javascript frameworks, and I left with a better understanding of how all of these fit together. Here’s the scoop:
The Headless Revolution - where is it going?
One of the first talks I went to was by a guy named Dean Barker, who gave a broad overview of the state of headless CMSs and Javascript frameworks today. In his talk he seemed to downplay the headless trend, stating that more and more headless CMSs would be forced to add traditional CMS features as their userbases expanded - “at a certain level of usage, there’s no such thing as an edge case.”
However, Barker did emphasize the benefits of the headless model, with presentation separated from content in order to more easily utilize different media channels. He also explained that headless was easier on developers, who only need to deal with the data served up by an API (and not with a particular CMS’s rendering pipeline).
Of course, his talk expounding the benefits of headless while casting doubt on newer, feature-poor CMSs put Sitecore in the best light, as it already separates presentation from content and has every feature you would want a CMS to have. Sitecore Javascript Services completes the picture with an API that allows developers to request batches of data from the CMS to be rendered with their Javascript framework of choice, be it React, Angular, or Vue.
After this talk I was excited to learn about the specifics of Sitecore Javascript Services. Being a Sitecore developer, much of my bread and butter is working with Sitecore’s layout and rendering engine, using MVC placeholders and HTML controls to render pages. I wanted to know how drastically different developing with JSS would be. Would I still be developing with an eye towards supporting the experience editor for our content authors? Would I have to throw out everything I knew and start from scratch? I got some of my answers in later sessions.
Sitecore Layout Service
To allow users continued access to features such as the experience editor and content personalization while using JSS, Sitecore provides something called the Layout Service. The Layout Service separates Sitecore from other headless+JSframework solutions. Instead of merely providing JSON data that represents items and field data from the content tree, the Layout Service utilizes Sitecore’s MVC pipeline to present layout and placeholder data through JSON as well. So instead of rendering markup, the rendering engine provides outlines for page layouts that are interpreted and rendered by Javascript frameworks. This separation of concerns allows content authors to continue building pages with Sitecore, blissfully unaware of the differences between React and Razor development.
Connected/Disconnected Mode
With JSS, Sitecore Developers no longer have to set up a Visual Studio environment connected to Sitecore in order to start developing. JSS allows developers to start writing and testing pages first, connecting them to Sitecore afterwards. This workflow is called “disconnected mode”, and it’s part of a “code-first” approach that Sitecore is promoting with JSS. The big advantage of this approach is that your front-end developers don’t need to know anything about Sitecore, as these Javascript frameworks can theoretically work with any API that offers JSON objects in the correct format.
However, apps created in disconnected mode can then be imported into Sitecore. Data schemas defined in disconnected mode will then be used to create the correct Sitecore template/item relationships. After importing, the developer will work in “connected mode”, wherein all data comes from a licensed Sitecore instance.
GraphQL
GraphQL were the low-key winners of this year’s Sitecore Symposium, being lauded in every presentation about headless and JSS that I attended. Put simply, GraphQL is a service that allows developers to refine the data returned from API calls. Sitecore describes it as “the ultimate SELECT statement.” In multiple demos I got to see how developers can use GraphQL queries to refine the format of the JSON data being sent to the front end. The GraphQL IDE, called “GraphiQL”, is also available and supported inside Sitecore, for real-time query testing.
Where does this leave us?
Although Symposium covered a lot of topics, JSS was arguably the star of the show. Sitecore knows Headless isn’t going anywhere, and with JSS they incorporate all the advantages that approach has, in addition to extending already-useful Sitecore functionality.
Just being able to develop for Sitecore outside of Sitecore is huge. I’d venture a guess and say there are a lot more React developers than Sitecore developers out there. It could be the case that we’ll start seeing more specialized roles in Sitecore dev teams, with Sitecore-agnostic front-end devs in addition to Sitecore-trained back-end devs. Only time will tell. However, with more companies choosing to go with React or other Javascript frameworks, it seems inevitable that “headless” Sitecore development is going to blow up.