Agenda

Architecture
Developer Experience
Supporting multiple frameworks

Our (Microsoft) story

Sitecore

1,000 Employees 50+ Countries 1,400 Partners 18,000+ Developers (C#, .NET, Windows) We offer a web-based CMS platform. Our ‘thing’ is personalization.

A website page is a hierarchy of UI components

Editing pages

Authors assemble components
Authors control layout

Editing pages

Authors assemble components
Authors control layout

Personalization

Update banner content based on user’s persona
Show personalized notification based on user’s cart content

Localization - Change social buttons based on user’s country

A/B Testing - Switch between 2 CTA styles to test which one drives more click-through

Personalization - Show personalized notification based on user’s cart content

Bottom line: page composition is not known at development-time

What does this mean for application architecture?

Bottom line: page composition is not known at development-time

MVC Workflow

JS layer depends on HTML produced by MVC Views
JS devs have to coordinate changes with back-end devs

Why did we want to -change- evolve?

Client implementation vs Platform

Front-end framework benefits

Faster performance - Faster, more efficient DOM reloading that makes sites/apps feel more responsive; DOM updates only when needed Easier maintenance - Well-defined patterns for setting up project, components, testing, etc Component re-use - Component-based design: Representing site content through self-contained components is the norm Robust data management - Application state is managed within the framework’s data models instead of scattered throughout the DOM Ecosystem - Big community of JS devs, huge ecosystem of tools and open-source libraries

So what's the issue?

The challenge with front-end frameworks

Developers control component layout

Component composition

React vs Angular vs Vue

JavaScript Services (JSS) to the rescue!

Three-year journey (and counting)

Initial POC proposal
POC
alpha
Tech preview
General availability

Initial idea

Render JS app server-side
Unplug from .NET
Clear FE/BE separation
Editor works

Placeholders in React components

Architecture (editor mode)

JS controller from POC ultimately became an independent REST service so it can be accessed from any context
JS layer physically decoupled from back-end layer (received data via HTTP post)

What if...

What if we could totally disconnect front-end development from .NET and Windows dependencies?

Disconnected development

Manifest data – locally defined static files (yaml or json) created by front-end devs are used to generate a “data manifest”. Define component schemas and content for later export to DB.

Local development – Use webpack-dev-server and create-react-app’s proxy feature to spin up a mock layout service.

Develop on a Mac without a VM

Sample App

JS controls data layer

JS devs push code to source control
Manifest generated on integration env
Integration env runs import tasks

Architecture (editor mode)

Architecture (end-user mode)

Biggest hurdle in headless proxy architecture is cookies
Using http-proxy-middleware

Tech preview - Go beyond React

Support multiple frameworks

Add Angular, Vue, React Native parity
Build app samples and Style Guides

Developer experience improvements

Add command line interface
Implement GraphQL

Solution complexity grows

Automate testing

“Being able to clone a repo, run npm install, and run a watch/browser syncing task and get right to work… That’s my jam! THAT feels like a modern, well done FED workflow”

Front-end devs love automation 🤖

Command Line Interface

JSS CLI (command-line interface) delivers a modern developer experience Before CLI, we deployed individual scripts to /bin Used for:

Creating new apps
Adding components
Disconnected development
App deployment
Data import to platform

Create a new JSS app is seconds with 3 commands

@AnastasiyaFlynn

Command Line Interface - Used Yargs

https://github.com/yargs/yargs/blob/master/docs/advanced.md#providing-a-command-module

Starter Kits

JSS has sample starter kits for each front-end framework

Provide an implementation starting point
Provide most common functionality such as routing and internationalization.

Each starter is based on popular starters

create-react-app
vue-cli
angular-cli

Starters serve as live documentation on patterns and best practices Supporting the starters – need to stay up to date with the various libraries Starters used for e2e testing

Automated e2e test suite

Cypress – testing library for anything that runs in the browser

Smokey (the e2e testing bear) Custom PowerShell scripts that we created in response to having to do a lot of manual testing.

GraphQL

Query language for your API.
Designed to support the frontend
Offers amazing tooling
Strongly typed, self-documenting
Avoids over-fetching or under-fetching

Allows front-end devs to work more independently @AnastasiyaFlynn

GraphQL Example

Monorepo

We started with a small number of packages A lot of manual maintenance As solution grew, we made the decision to move to a monorepo

Monorepo benefits

Simplified organization
Simplified dependencies
Tooling
Cross-project changes

Monorepo cons

Tags less useful
Potential performance issues

Monorepo powered by lerna.js

Lerna – a tool for managing JS projects with multiple packages https://github.com/lerna/lerna

Manage your project using one of two modes: Fixed or Independent.

Monorepo powered by lerna.js

lerna publish

lerna will prompt you to update the package(s) version, choose accordingly between major/minor/patch
lerna will publish the packages to npm
lerna will also update package.json files for the samples and packages
Commit updates and push to master as part of a tag commit, in which a tag will also be added for the version that was published.

TypeScript

Iterative process during Tech Preview Initiated by community feedback Wanted TS users to have an easy time consuming our libraries.

Benefits

Intellisense
Easier for TS consumers
Our codebase reached the point of complexity where having inter-library contracts and type checking was super useful

Documentation – make it searchable

https://community.algolia.com/docsearch/

Summary

Overhead of supporting multiple frameworks

Build frameworkagnostic manifest generation
Refactoring to monorepo
Custom automed e2e tests
Overhead of framework + cli dependency upgrades
Supporting the starter apps, Normalizing scripts
More documentation needed

Focus on developer experience

In building our JS layer, we wanted to make sure we are building something that JS devs will actually want to use.

Focus on developer experience

Intuitive to use

CLI
TypeScript definitions
Comprehensive, searchable docs
Quick start guide

Empowering

GraphQL integration
Manifest-driven data-modeling

Supports independent workflow

No need to learn Sitecore
Any framework
Any OS
Work without installing Sitecore

Want to learn more about our SDK?

Repository https://github.com/Sitecore/jss Free developer trial https://www.sitecore.com/trial Docs https://jss.sitecore.com/docs