In the following outline I will take you through some learning points that Aceik discovered on our first JSS project. Some of this is personal opinion and based on our experience with the Angular framework.
Disconnected Mode – Get started quickly
If your team is just starting out and you want to see JSS in action you will likely start out running in Disconnected Mode. This seems like a great way to get non Sitecore developers up and running without them needing to run an actual Sitecore instance. A key benefit is also that front end developers in your team can work on the project without having any Sitecore skills.
It has been mentioned by Nick Wesselman in the global Sitecore slack (Hi Nick, hope its ok if I quote you) that:
“*I wrote the import process for JSS and I can tell you it was not intended for anything beyond quick start for front end devs and short lived campaign sites”
“Sitecore-first was always the intended workflow for anything non-trivial”.
I have to be honest I was disappointed when I read the above comments as we did get a fair way into the project supporting our front end Devs and our backend Devs. It does make sense though that Disconnected mode has its limitations. Your not going to get all the bells and whistles available that Sitecore provides, without actually having Sitecore itself. Still the opportunity to support those developers that don’t know Sitecore is a big draw card and I for one see Disconnected mode as something that is very useful.
Disconnected Mode – Example usage
From personal experience building out a member portal in Angular we were able to mock up secure API calls in Disconnected mode by detecting which mode the app was run in. The workflow involved building individual components that were verified to be working in Disconnected mode by front end developers. These same components were then verified in Connected mode running in Sitecore. Some people may consider this to be double handling in some ways. I still think the the benefits of continuing to support front end developers has its advantages.
GraphQL is a paradigm shift from traditional APIs in that you have a single API endpoint that you can run queries and mutations against to produce results and updates.
Custom GraphQL Endpoints
A couple of things that took us a while to figure out were
- Adding multiple schemes to our single endpoint.
- See Example Line 134
- Sending mutations with complex object structures (Nested POCOs)
How to Turn on Mutations
If you need to send updates to the server by convention in GraphQL you write these as mutations.
You won’t get far unless you actually enable mutations in your JSS app config. This might seem obvious but it took us a while to find an example and work it out.
See Example Line 128
<mutations hint="raw:AddMutation"> <mutation name="createItem" type="Sitecore.Services.GraphQL.Content.Mutations.CreateItemMutation, Sitecore.Services.GraphQL.Content" /> <mutation name="updateItem" type="Sitecore.Services.GraphQL.Content.Mutations.UpdateItemMutation, Sitecore.Services.GraphQL.Content" /> </mutations>
Secure vs Insecure Graphql Endpoints
Something we required in the case of our member portal project was custom GraphQL endpoints for logged in users and in some cases insecure endpoints for data that did not require an Authenticated user.
Essentially in Angular we solved this using multiple Apollo clients. A full example is available here: (along with detailed explanation)
That’s a wrap for some of our key JSS learnings so far. We may come back and add to these over time as we learn more. Happy JSS-ing !!