リクエストしたページはご希望の言語ではご利用いただけません。

DEVELOPING DIGITAL | EPISODE 2

Ahead with headless: JavaScript Services for Sitecore

In this episode, Sitecore’s own Kam Figy and Adam Weber, platform architects for JSS, join Derek Dysart to talk about how they brought JSS to the Sitecore platform to open up the full potential of Sitecore as a headless CMS.

Listen now

Listen to the episode 

Introduction

With Sitecore JSS (JavaScript Services), developers can create apps working in their preferred frameworks without having to know Sitecore, and still take advantage of the great CMS and personalization capabilities of the platform. Kam Figy and Adam Weber, Sitecore architects on the JSS team, talk about how they brought JavaScript Services (JSS) to the Sitecore platform and explain in depth the range of possibilities this opens up for creating powerfully dynamic, scalable apps.

Read the episode transcript →

 

 

 

 

Transcript

Derek Dysart:
Gentlemen, welcome to the podcast.

Kam Figy:
Thank you.

Adam Weber:
Thank you for having us.

Derek Dysart:
Why don’t you take a minute to introduce yourselves and say what your roles are?

Kam Figy:
I’m Kam Figy, and I’m a developer on the JSS team.

Adam Weber:
I’m Adam Weber, also a developer on the JSS team.

Derek Dysart:
For people that might not be familiar, what is JSS?

Kam Figy:
JSS is Sitecore’s entry into both the headless CMS space as well as a way to build single-page apps with modern JavaScript frameworks with Sitecore.

Derek Dysart:
Okay, so when we talk about a headless CMS, what is – you know, especially being on the team building this out – in your mind, what is a headless CMS?

Adam Weber:
I mean, at its core, a headless CMS is just about any CMS where you separate the delivery of final rendered content from the data that defines that content. 

Derek Dysart:
Okay.

Adam Weber:
I mean, in that sense, Sitecore has always separated its rendering from its content data, so it’s always been capable of being a headless CMS, and there have always been services that it’s implemented that have given you content data. It’s just with JSS we’re bringing a lot more and more useful services when you’re trying to do specifically what these days is considered headless CMS where you’re completely disconnecting your rendering setup from the CMS back-end, like physically separating them, not even necessarily using the same programming language for them.

Derek Dysart:
Sure, sure. And, Adam, you were part of the initial development push to build out JSS.

Adam Weber:
Yeah.

Derek Dysart:
What was the thinking behind when it was built?

Adam Weber:
When we were starting, it was just very experimental. Headless wasn’t even on the radar. We had seen what some of the community members were building around Sitecore in React. We had had some experience building on React, and we liked it. We just kind of wanted to see what we could do with React and modern JavaScript and Sitecore and out of that was born the initial layout service prototype as well as the initial React framework support.

Derek Dysart:
Yeah.

Adam Weber:
And it just evolved rapidly from there. Somewhere along the way we introduced headless proxying and the ability to go completely disconnected from Sitecore.

Derek Dysart:
Explain exactly what that – what does that really mean when you’re saying it’s disconnected from Sitecore?

Adam Weber:
There are two ways of looking at it, I guess. We’re talking both about disconnected development, right? That’s one of the modes that we provide as you’re building a JSS app –

Derek Dysart:
Yes.

Adam Weber:
You just run a local development server with, you know – on any platform, Mac, whatever, and you’re able to rapidly build your application and iterate on it and, you know, basically prototype it for use within Sitecore.

Derek Dysart:
Yeah.

Adam Weber:
The other aspect of disconnected that I was talking about is back to the headless concept of content delivery, right, where you’re – like Kam mentioned, where you’re completely decoupling the content delivery from rendering, right? And so you would have potentially, you know, a node instance out on the edge handling all of the requests for your application. Everything’s, you know – then content requests are just coming to Sitecore, and that’s all that’s happening, but all the rendering is happening in node or in your JavaScript application.

Derek Dysart:
So, Kam, you had started talking a little bit about how Sitecore has always been headless in its nature. I think, you know, for a developer that hasn’t built on Sitecore in the past, it’s probably – you know, speaking as somebody that’s developed on the platform, it’s one of the – probably one of the interesting points of the platform of how presentation is decoupled from the actual data that’s being presented on the various pages. I guess, when looking at JSS and how it’s decoupled, what are you gaining, you know, by having, say, a single-page application using JSS to get data out of Sitecore? I guess, what is that buying both the developer and the marketer?

Kam Figy:
I mean, there are two main advantages that you get out of having a single-page app on top of Sitecore. The first is that it runs at the client side as opposed to running at the server side, so you gain, you know, bandwidth enhancements because you’re able to change pages and just pull the data necessary for the new page as opposed to pulling the entire markup for the page, like you’ve got components and you just pull the data and then re-render using the new data.

Derek Dysart:
Yeah.

Kam Figy:
The second one is that, because it runs at the client, you can execute much more logic. If you do a traditional Sitecore MVC app, for example, the server renders a page that’s full of HTML. Once it gets to the client, it kind of is fixed - like you can run JavaScript and change parts of it or do, like, a carousel or something using data already on the page. But by and large the structure of that page is fixed as soon as the server has rendered it - whereas in a single-page app it’s pretty much the whole app is executing within the browser. So you can be exceptionally dynamic with what you do, you know, switching routes, changing data, pushing events back to Sitecore, all sorts of other things that would be very difficult or would require much less native-feeling implementations if you were doing it with the server side rendered setup that just returned markup and was not JavaScript.

Adam Weber:
It’s also – it’s not always just about what you gain out of it. It’s about what you’re not giving up by using JSS on top of Sitecore, and that’s kind of been the mantra behind everything is that it’s delivering no-compromise Sitecore solutions.

Derek Dysart:
[Nods]So, you know, for somebody that may not be familiar with Sitecore –

Adam Weber:
Right.

Derek Dysart:
– what is, you know, what does that really mean?

Adam Weber:
Right, and so what that means is in a traditional headless scenario for Sitecore people have been trying to build, you know, single-page apps on Sitecore for years. They’ve done it with success, but you typically have tradeoffs, like you lose personalization, you lose all the marketing features – you know, all the marketing platform features. You lose Experience Editor support typically, you know, workflow management. Just a lot of features that come in the platform –

Derek Dysart:
Yeah.

Adam Weber:
– you lose by going that way traditionally, but with JSS you don’t lose any of that stuff. It’s – everything’s – like I said, you retain the entire feature set of the platform.

Derek Dysart:
Right. And so, in practice, I guess, what does that look like? You know, you can be using the app and then actually edit the content directly in place?

Adam Weber:
Exactly. You have – the app is – because it’s rendered server side, it’s – the browser is receiving the HTML from the app, right, that’s rendered by the server and it’s all – we can mirror the HTML that a standard Razor site would emit, right? It’s everything that Experience Editor is expecting and that it needs to function – so your app is rendered – your JavaScript app is rendered as HTML, and then Experience Editor can take over and you can add components, add renderings, you know, do all the manipulation that you expect –

Derek Dysart:
[Nods] Interesting.

Adam Weber:
– including personalization –

Derek Dysart:
Sure.

Adam Weber:
– and content testing and all of those things.

Derek Dysart:
So if I’m a developer, you know, maybe I’ve got a background in, like, a JavaScript framework like React or Angular or Vue, which are the – correct me if I’m wrong – are kind of the three frameworks that are being supported –

Adam Weber:
Correct.

Derek Dysart:
– with JSS, what do I need to do to get started and, you know, what is the – from a high level, what does the process look like for getting a development environment up so I can actually start to develop that app and get it connected to Sitecore?

Adam Weber:
Sure, so we’ve tried to make it as straightforward as possible for anyone having a JavaScript background. It shouldn’t be anything foreign to them, you know. It’s a matter of installing some npm packages into their app if they want. If they already have an existing app or, you know, just want to integrate JSS into it, or if they want to use one of our sample apps as a starting point, Kam has done an amazing job building out the JSS CLI that allows people to quickly, you know, with –what? four commands? –

Kam Figy:
Yup.

Adam Weber:
– get the CLI installed and then get a sample app up and running.

Derek Dysart:
So talk about that a little bit, Kam. What is the JSS CLI?

Kam Figy:
So the JSS CLI is – it’s a command line interface that is based in Node.js and has a lot of similarities to the command line interfaces that are common in the frameworks that we support –

Derek Dysart:
Sure.

Kam Figy:
– so in Angular there’s the Angular CLI.

Derek Dysart:
Right.

Kam Figy:
In Vue there’s the Vue CLI, and in React it’s Create React App. They all have console commands that you can run essentially to do standard actions on those applications, so we built our own command line that does the JSS specific things that you would need to do. For example, there’s a scaffold command that we ship within our sample apps that lets you quickly scaffold out a new component in our JSS app. There are deployment commands that let you import your disconnected JSS app into Sitecore.

Derek Dysart:
Yeah.

Kam Figy:
We have some Sitecore-first, as we call it, scaffolding commands that actually let you scaffold the component but directly within Sitecore, so if you’re working without any disconnected content and you’re just connected to Sitecore you can still quickly scaffold the JSS component within Sitecore. So, like, if you’re a front-end developer and you don’t want to deal with the minutiae of how you connect a data source template to a rendering in Sitecore –

Derek Dysart:
Yeah.

Kam Figy:
– the scaffolder will do it for you.

Derek Dysart:
Sure. Both of you have kind of been – I mean, JSS has been in tech preview for probably a little over a year now, and as you’ve seen people use it, what are some interesting things you’ve seen people use JSS to do?

Kam Figy:
We’ve seen a lot of interesting things.

Adam Weber:
Yeah. I mean, just seeing the adoption rate, like, the excitement behind it is what’s most exciting for me, I guess.

Kam Figy:
Yeah, there are a lot of people who are extremely excited that they can start using these JavaScript frameworks with Sitecore because they can see the advantage in running an app client-side, but it’s been difficult to do with Sitecore until JSS.

Adam Weber:
The only specific thing I can think of is one of our partners has built, like, a commerce accelerator – based on JSS, right, and the initial – one of the initial integration points between JSS and commerce. They were able to rapidly prototype and set up new commerce-based sites, you know, backed by Sitecore commerce but completely front end-driven.

Derek Dysart:
Right.

Adam Weber:
Everything’s out there, and, you know, all the data’s still coming from Sitecore.

Derek Dysart:
Sure.

Adam Weber:
It was a pretty cool demo to see.

Kam Figy:
And we’ve also seen, for example, when you start doing progressive web apps – like Adam did a demo on it and then we’ve had some other partners that have worked on things like that too – with a service worker running in your browser, which is a core piece of a progressive web app, you have the ability to control the caching that the browser does within a background process that executes within the browser –

Derek Dysart:
Okay.

Kam Figy:
– so essentially it’s like having a background thread for your JavaScript, but it can also interact with network requests your app makes. In the case of our sample app, what Adam did was make it so that when you changed routes with layout service it would cache the layout service response within the browser using programmatic cache invalidation, so you were able to make very, very quick changes between routes in the application because it already had the data –

Derek Dysart:
Sure.

Kam Figy:
– and then it would quietly go re-fetch the data in the background to see if anything new had happened. Then it would update the cache. There are a whole bunch of things that you can do with service workers. You know, you can pre-fetch all the routes in an application or something. If you know people are going to be switching between many different routes, you can have it be, like, completely instant to change routes with no network request at all.

Derek Dysart:
Right.

Kam Figy:
You can run offline because when you have it in your cache the service worker can essentially fake the server being online and give you the data from cache without needing to hit the network, so that’s how, you know, things like Google Docs and things like that do work offline is that they run something like a service worker that stores things from cache locally.

Adam Weber:
One of the other cool things that JSS opens up and that we have experimental support for is native applications as well, so, you know, just dovetailing with what Kam said about PWAs, using JavaScript to build a completely native app, right? Using React Native is what we’ve been working on. I haven’t seen any specific examples out there, you know, that customers or partners are building, but the capability is certainly there and still –

Derek Dysart:
And it’s still early in the products.

Adam Weber:
– and still delivering, you know, all that personalized testable data to a native app.

Derek Dysart:
[Nods] You initially talked early on about working in kind of disconnected mode. You know, for a developer, does that really mean that you can truly work in the DevTools that you’re used to? You’re not – you know, you don’t need a stand-up. You don’t need to be a .NET developer, don’t need Visual Studio. You can work and develop your app that’s going to connect to Sitecore without any of those tools?

Adam Weber:
Absolutely. That’s been – always been one of the primary goals of JSS, you know, once we realized that we were actually on to something here after the initial prototype was to not disrupt a typical JavaScript or front-end developer’s workload, right? They should be able to use all of the tools that they want in the manner that they’re used to with only what we used to call “sprinkles of Sitecore” –

Derek Dysart:
Okay.

Adam Weber:
– mixed in, right? They shouldn’t have to learn the entire platform in order to get their job done. And to that end, I think we’ve done a pretty good job of keeping it – you know, trying to stay as much out of their way while still delivering a great developer experience.

Kam Figy:
Yeah, I mean, essentially the way that the JSS apps work is that we’ve taken sort of the idea of the Sitecore layout engine and extended it to the client so components are dynamically placed, and that’s probably the single biggest thing that might be alien to some front-end developers is the dynamic composition of components on a page because most frameworks mostly statically compose components.

Derek Dysart:
I think to pick that apart a bit, that’s really – you know, if you’re not familiar with it, I think a Sitecore developer may glom onto that right away, but I think it’s –

Kam Figy:
Yes.

Derek Dysart:
– you’ve got an app that, you know, has components in it, but those components are placed at runtime.

Kam Figy:
Exactly.

Derek Dysart:
They’re not – you know, you’re not like, okay, we’ve got our header, and then we’ve got our carousel, and that’s – one always follows the other. Those are actually laid out at runtime, and it’s part of the data that Sitecore is ultimately going to provide to the app.

Kam Figy:
Exactly. To some extent, the part of Sitecore that a JavaScript developer would need to be conversant with is the way the layout structure works with placeholders and renderings placed within those placeholders. And that’s kind of the extent of what we force people to learn about Sitecore –

Derek Dysart:
Sure.

Kam Figy:
– because that’s really the extent of what’s necessary to be able to render something that’s like Sitecore on the client. Beyond that, we did our best to make all the sample apps as idiomatic to their framework as possible –

Derek Dysart:
Yeah.

Kam Figy:
– so we want the Angular app to feel Angular-ish. For example, the Angular app is using Angular’s HttpClient to make layout service requests because that’s how it would be done in Angular, but in React we’re using Axios, which is more idiomatic for React.

Derek Dysart:
Yeah, and I think that’s – and that’s, I think, what Sitecore brings to the table on this is that history of that layout engine, that the actual presentation is stored as content alongside the content, which, that’s where you get great – you know, you get the great personalization rules that now you can have data-driven layout and the layout on there is driven off of data, whether it’s coming from analytics or it’s coming from the actual session or what have you. Adam, you kind of talked little bit about native apps, and I know you had mentioned you’re looking at React Native, but what else does that open up? You know, if you’re looking at using JSS, are you necessarily limited to only JavaScript frameworks?

Adam Weber:
No, you’re not, actually, because JSS is actually an SDK, right? It’s a number of tools and services that come together to form, you know, what we’re calling JSS, but it’s really – it’s the JavaScript modules or packages that we ship. It’s also layout service. It’s also the GraphQL endpoints. In all of those things combined, you can pick and choose which aspects of JSS that you actually want to use, and none of them are really – well, the JavaScript stuff is dependent on layout service, but you can use layout service data in anything that can understand JSON, right, that can consume and process JSON and knows what to do with the serialized presentation that we’re sending.

Derek Dysart:
[Nods]So what does that open up for the developer then?

Kam Figy:
I mean, essentially when you have layout service it lets you take the layout defined in Sitecore, the component structure, and that component structure may be conditional based on personalization rules, so you can get essentially personalized JSON that defines a layout of components to anything that understands JSON.

Derek Dysart:
Sure.

Kam Figy:
And that opens up a lot of possibilities because you – I mean, it doesn’t even have to necessarily be used for a component layout. It’s just data.

Derek Dysart:
Yeah.

Kam Figy:
It has a component name attached to it which allows you to render a named component there if you want, but it doesn’t care if you’re rendering in Swift. It doesn’t care if you’re rendering in React. It doesn’t care if you’re rendering in Java.

Derek Dysart:
Right.

Kam Figy:
Anything that pulls JSON can use the layout service data or the GraphQL data or anything like that, so what it enables you to do is get personalized data out of Sitecore, like there’s a demo that we’ve been working on where we’re actually using Sitecore to personalize a text tree, like a conversation tree. Based on previous choices, we will personalize the later choices, and that’s all powered by layout service, but it’s not really a layout per se.

Derek Dysart:
Sure.

Kam Figy:
It’s personalizing stages of a conversation.

Derek Dysart:
Yeah, yeah. You mentioned GraphQL earlier. What is – how does that play with kind of the JavaScript services that we have?

Kam Figy:
Okay, so, I think most people are probably familiar with REST APIs where you return HTTP status codes and you get JSON back and you can have primaries and that sort of thing, so GraphQL is sort of a parallel idea to REST, but it is not REST. It’s essentially a protocol that runs over HTTP but allows you to query a graph, like a strongly typed graph that is a schema of data.

Derek Dysart:
Okay.

Kam Figy:
That sounds really abstract, but for a very concrete example, you could have a schema that lets you query Sitecore content. You could (using GraphQL, for example) write a query that says I want this particular item, I want its children, I want the page title field that is defined on it, and also that I want to know all the fields that are available on its template.

Derek Dysart:
Okay.

Kam Figy:
So you can – and that’s because the item in the schema graph has various axes and nodes that you can traverse underneath it (for example, children or template). Then you can tell the GraphQL server what node of the graph you want, and it will basically go and resolve just that data for you that you asked for, unlike a REST service, where it’s usually, hey, I want to get this item and it just dumps 30 fields back from the item but you only cared about two, so you just wasted a ton of bandwidth and probably a lot of latency doing that. In GraphQL you send it a query, and you say, hey, I want the ID and the path, and all you get back is the ID and the path. I mean, GraphQL has tremendous amount of advantages in other ways as well, like it’s actually a strongly typed schema. What we’ve done, for example, with the content API is we actually have emitted GraphQL types for all of the templates that you define, so you can make strongly typed queries in such a way that they are validatable GraphQL queries that are pointing at fields that we know are defined in your template. It’s – for Sitecore developers, it’s almost like a Glass Mapper except it’s in JavaScript, and you could do the same sort of validation with, like, say, ESLint that it matches your GraphQL schema and is valid.

Derek Dysart:
Gentlemen, hey, thanks again for sitting down to talk about the stuff that’s with JSS. If folks want to find out more, where can they find information online?

Kam Figy:
Probably the easiest way would be go to the documentation site, which is just jss.sitecore.net.

Adam Weber:
Yeah, otherwise, if you have questions or anything like that, find us on Slack, Sitecore Stack Exchange.

Kam Figy:
Yeah, and for Slack, it’s the Sitecore Community Slack. If you google that, you will find a form to help you join it.

Derek Dysart:
Sure. Great. Well, thanks again.

Find events near you

現在地を使用

Change my location

適用