May 28, 2019
Roughly five months ago we started having discussions with a client about their internal development practices and approaches. Things like headless, and Vue started cropping up a lot and so we decided to pivot our technical approach to align more with their internal methodologies.
What to expect from these posts?
With a few months of development work under our belt, and a production instance of JSS now running, I wanted to share some thoughts on quite how that experience has been.
We'll cover things like what it’s like to move from being a traditional Sitecore dev to a JSS dev, how to get everything deployed, any gotchas we didn't estimate for when we started and some key design decisions we made along the way.
How do you get started?
I think the first question you need to ask is: will JSS be the right choice for us? We'll revisit that question later, but for now let’s assume yes.
The four key reference points we've relied on have been:
- https://jss.sitecore.com/docs the JSS docs site
- https://github.com/Sitecore/jss- the JSS github repo
- https://sitecore.stackexchange.com/questions/tagged/jss- the JSS channel in Sitecore Stack Exchange
- The JSS channel in Sitecore slack
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.
What's next
As you read this the follow-on posts are being curated. The aim is to cover things like:
- What's it like building a JSS application?
- Designing and building the infrastructure you need to run a JSS application
- How do you deploy JSS?
- And a few more ideas and gotchas we've hit throughout the process
Summary
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...
