The four key reference points we've relied on have been:
Getting your first disconnected JSS app running is trivial - you need to pick the framework of choice, run a few commands and you should see the starter kits running out of node on your local dev machine.
What tools do you need?
This may well be down to personal preference, so people will have their favoured IDE's. My tools of choice would be VSCode for any JSS development and Visual Studio for any Sitecore development. Simple :)
If you want to run connected mode, you'll need a sql server instance, IIS and a licenced Sitecore instance.
Key design decisions
There are a raft of decisions you can make as you build out your implementation - ranging from things like, which framework to use through to what pages do you proxy or, do you even run a proxy?
A few key design concepts we decided on throughout the build were:
- Custom content resolvers in favour of GraphQL
- We'd proxy everything, including old legacy Razor Sitecore pages
- Sitecore first - all content would come from a Sitecore instance in a structure we defined. Not from offline YAML files or an imported structure.
Choosing a language and framework
Much like the IDE debate selecting a front-end framework can be a very contested issue. We've been using Vue, SCSS and where possible TypeScript. FYI the soon to be released V3 of Vue will bring much better TypeScript support.
To provide dependency injection capabilities and adequate TypeScript support we opted for the npm packages: Inversify and Vue-Class-Component.
Hosting, infrastructure and devops
Quite a broad topic which we'll explore in more detail later - as a top-line summary we:
- Host Sitecore in Azure, deployed via ARM templates from Azure Devops
- Host JSS in AWS, deployed via Cloudformation into Beanstalk from Azure Devops
The development team
We come from a traditional Sitecore dev background so are very used to configuring SQL dbs, setting up Sitecore templates, building razor views and the associated JS/CSS. All with a devops focus within the team. I don't feel like any of this has hindered our JSS adoption.
As you read this the follow-on posts are being curated. The aim is to cover things like:
This isn't meant as a comprehensive 'you have to do things this way' series of blog posts. This is how we've approached the problem and the snags we've hit along the way.
"Will JSS be the right choice for us" - watch this space...