Den side, du har bedt om, er ikke tilgængelig på dit sprog.

DEVELOPING DIGITAL | EPISODE 1

Headless and the development workflow of your dreams

Welcome to our podcast series. In this episode, we'll discuss all the possibilities Sitecore’s headless CMS technology, with JavaScript Services, opens up for developers.

Listen now

Listen to this episode

Introduction

From ideation to prototype to iteration, a headless CMS makes it possible for developers to move quickly. It also allows back-end and front-end developers to work at their own pace, and free from anxiety over future integrations. In this episode, Alex Shyba, co-founder of Altola Digital, joins Derek Dysart to discuss the powerful functionality made possible by Sitecore’s headless CMS with JavaScript Services. By reflecting on his presentation at Symposium, where he went from design to deployment of a site in 40 minutes, Alex highlights all the possibilities a headless CMS opens up.

Read the episode transcript →

 

 

 

Transcript

Derek Dysart:
Welcome to the podcast.

Alex Shyba:
Thanks, Derek.

Derek Dysart:
Alex, for folks that may not know you, can you give a little bit of an introduction?

Alex Shyba:
Sure, sure. I’m Alex Shyba. My background is full stack, so I’ve been a Sitecorian for a decade—over a decade—before starting my own firm with Todd Mitchell and Lars Petersen. It’s a boutique experience agency called Altola.

Derek Dysart:
Okay, okay.

Alex Shyba:
So I’m kind of bringing all of that Sitecore experience in various areas now on the other side of the fence, helping with adoption of these cutting-edge technologies that I had a chance to contribute to.

Derek Dysart:
Nice, nice. At symposium you did a presentation kind of outlining some of the features that are available in Sitecore for someone, you know, using it in a headless manner, and I guess, before we kind of dive into that, I think when you think of a headless content management system, what exactly does that mean to you?

Alex Shyba:
To me, to put it simply, it’s a CMS that has no business in rendering—

Derek Dysart:
Yeah.

Alex Shyba:
—so it ends at the API boundary. Then final presentation of output is the job of another layer, so it’s kind of a physically decoupled CMS. 

Derek Dysart:
Yeah, so, I think—the way I hear that is a typical CMS is going to output HTML and markup, and something that’s going to be consumed in a browser gives a nice authoring experience to somebody trying to manage the content. I mean, content management is right in the name of the tool, but in a headless manner you’re kind of saying we may not be outputting it as a webpage. It’ll be consumed from somewhere else.

Alex Shyba:
Yeah, because you may have a mobile device rendering it natively and CMS is a web channel tool—

Derek Dysart:
Yeah

Alex Shyba:
—and so there is no way to really do that job so why bother in the first place?

Derek Dysart:
Yeah. So let’s talk about the presentation you gave. You gave a demonstration. Maybe you could kind of recount it for the listeners.

Alex Shyba:
Yeah, my approach was kind of different because there are lots of JSS talks covering features and functionality, so I wanted to—

Derek Dysart:
And so when you say JSS, what do you—

Alex Shyba:
Sitecore JavaScript Services, yeah.

Derek Dysart:
So that’s kind of the portion of Sitecore that allows you to consume Sitecore from JavaScript frameworks.

Alex Shyba:
That’s right. Yeah, it’s one way of doing headless, and it’s a lot of different things. At the core is a new API that lets you access page model—

Derek Dysart:
Okay.

Alex Shyba:
—so you tap into this multiyear investment and contextual content delivery that Sitecore has made, and you make it available as an HTTP endpoint.

Derek Dysart:
Okay.

Alex Shyba:
That’s what’s called layout service. It’s contextual, meaning it’s personalization-enabled. It knows who the consumer is so you can personalize the output. You can do A and B testing of your components. That is a part of this markup, so think about it as a structural presentation layer. It’s tracked, so you get analytics, out of the box. It’s a very cool thing, and it’s a .NET MVC base, so it’s the rendering engine we know—

Derek Dysart:
Yeah

Alex Shyba:
—and have repurposed for all the clients, not .NET clients.

Derek Dysart:
Okay.

Alex Shyba:
And so that was critical for JavaScript. Another big piece is a set of packages, so it’s an SDK for React, Angular, and Vue—

Derek Dysart:
Okay.

Alex Shyba:
—and some experimental React Native packages that kind of bring components—Sitecore placeholder component that is able to render components from that layout service output and some helpers to be able to translate fields coming out of Sitecore into something manageable, renderable inside of that environment.

Derek Dysart:
Yeah, so, I mean, is—JSS isn’t just one thing. It’s kind of a suite of services.

Alex Shyba:
It’s a salad bar kind of—so you pick what you want. Another big part is a code first, which is kind of—it’s very different from any other kind of hybrid headless CMSs out there. It’s ability to detach from CMS during development—

Derek Dysart:
Yup

Alex Shyba:
—so you’re running local mark services.

Derek Dysart:
Okay.

Alex Shyba:
So that means you can run on non-Windows environments—

Derek Dysart:
Sure.

Alex Shyba:
—and do initial phases of development, prototyping without CMS being installed or available for you as a front-end developer.

Derek Dysart:
Great.

Alex Shyba:
And then you script the process of bootstrapping your app with Sitecore CMS. You kind of work with these abstractions in JSON, YAML, or JavaScript, and you bring what the app needs into Sitecore in the automated fashion, so that’s what’s known as code first. You don’t have to do that, but that’s an option. It works for some projects in front-end-led teams where you want your front-end developers to do a little bit more than just, you know, front end and behavior and all that. You actually want to have them shape contract for your components—

Derek Dysart:
Uh huh

Alex Shyba:
—and so some like that because it empowers them to do more and they’re less dependent on back end.

Derek Dysart:
Okay.

Alex Shyba:
So that’s what enables kind of this two-speed architecture—

Derek Dysart:
Sure.

Alex Shyba:
—in a way where back end is moving on its own pace and front end can evolve and move much faster.

Derek Dysart:
Nice, so, kind of getting back to the demonstration you did, you kind of demonstrated how vast you can actually move as a developer in actually producing, you know, some consumable output, I mean, in an actual functioning website. I wonder if you could talk a little bit of how that went?

Alex Shyba:
Yeah, it was an ambitious goal of getting from design to deployment in 40 minutes, so I had to streamline certain things to make it happen.

Derek Dysart:
Uh huh.

Alex Shyba:
The idea is you start with a design tool that lets you work in atomic design—

Derek Dysart:
Okay.

Alex Shyba:
—where also you work off components, you design behavior interactions, and that tool produces React codebase—

Derek Dysart:
Okay.

Alex Shyba:
—which is kind of cool, which then you take as a front-end developer. You clean it up. You plug in other parts of your stack, the styling library that you like, state management that you like, but you already work—you got, you know, 60% of front-end code from the design tool—

Derek Dysart:
Sure.

Alex Shyba:
—which is kind of awesome.

Derek Dysart:
And what was the name of that tool that you used?

Alex Shyba:
React Studio.

Derek Dysart:
Okay.

Alex Shyba:
I just recently discovered that last week. [laughs]

Derek Dysart:
Okay.

Alex Shyba:
Most design tools that work in this kind of component-centric world, they stop at that state. They don’t want to produce production-ready code. These guys figure it out, and they double down on that approach.

Derek Dysart:
That’s interesting to hear because a lot of times you work with tools, especially if they’re generating code—you know, I think back to early days of the web. You’d have, like, Photoshop. Photoshop, you could have it output a sliced-up document that was HTML, and it was—you know, no developer in their right mind would actually use the HTML that came out of that. They would, you know, definitely want to tweak it and optimize it, so that’s interesting to hear a tool like that is actually, like you said, producing production-ready code.

Alex Shyba:
I think it works better because it’s—I’m not 100% certain, but I think it’s—under the scenes it’s React rendering inside of that tool—

Derek Dysart:
Oh, okay.

Alex Shyba:
—so it’s a tool for a Mac because React is diagnostic of any rendering target—

Derek Dysart:
Sure.

Alex Shyba:
—of HTML. It could be console. It could be, you know, a design tool. So I think the high fidelity of that code comes from that—the fact that it’s all React under the scenes so it’s not like one technology and then you translate into another technology.

Derek Dysart:
Okay.

Alex Shyba:
I think it’s—it has some legs definitely, so after you have that code base, then you do your front-end work required to kind of make it more production-ready, and then you JSS-ify it—

Derek Dysart:
Sure.

Alex Shyba:
—so you add sprinkles of Sitecore SDK on top of that code base—

Derek Dysart:
Yeah.

Alex Shyba:
—so instead of static texts you use Sitecore primitives to make sure text will be coming from CMS.

Derek Dysart:
Sure.

Alex Shyba:
And the next phase you deploy it so at the end of the process you’re almost prepped for, you know, one script, one command to pull into Sitecore Instance.

Derek Dysart:
Yeah. So you kind of built the application out, had some, I don’t know, placeholder text where, you know, you’re going to eventually drive the content out of Sitecore. Then once you took that out of React Studio, you basically dropped in the native part so it would pull information from Sitecore.

Alex Shyba:
Yeah, so that code-first model lets you work with this marked Sitecore service that all you need is specified content in YAML or JSON or JavaScript—

Derek Dysart:
Yeah.

Alex Shyba:
—register these components with this manifest through JavaScript APIs. Any front-end developer can do it. So you shape contract for all your components. These are the fields, the different field types. This is how I want them to be displayed in CMS.

Derek Dysart:
Uh huh.

Alex Shyba:
And it’s not—it’s kind of opt in so you don’t—you can spec out component down to, like, validation settings—

Derek Dysart:
Sure.

Alex Shyba:
—on every field but you don’t have to do it. All you need is to specify component name, here are my fields, that’s how they’re named, so it’s a very progressive approach. You can take it to 11, but you don’t have to.

Derek Dysart:
Sure, sure.

Alex Shyba:
Then the beauty of Sitecore JavaScript Services is also server-side integration with .NET, so by deploying the same app you build the front-end dev into CMS as the same app that runs service side inside of the CMS environment.

Derek Dysart:
Okay.

Alex Shyba:
Sitecore's approach to headless is hybrid, so you can do physically decoupled, but you can also have your app rendered inside of the Experience Editor, the in-context WYSIWYG editing tool.

Derek Dysart:
Yeah, so that gives the content author the ability to edit fields in place in the app, which is—

Alex Shyba:
They would never know it’s a JavaScript application.

Derek Dysart:
Right, right, and that’s, I think, an interesting point is that you get a lot of content management systems where it’s—you know, you’re just buying an author and an environment, making it easier for folks to author stuff, but you can actually leverage all of what Sitecore brings to bear on that, not only being able to, like you said, use the WYSIWYG but then use the personalization services within there as well.

Alex Shyba:
Yeah, so that third chapter was to decorate the app with marketing features like personalization, personalize a component, and afterwards you figure out how you want to deploy this app.

Derek Dysart:
Sure.

Alex Shyba:
That’s another set of good surprises is that you now have so many options how you want to deploy your app—

Derek Dysart:
Yup.

Alex Shyba:
—how you can deploy your app. By physically decoupling or rendering, you can have server-side Node sitting on any Linux server to render it on any [unintelligible] managed. Node.js environment would be able to render your app, so you don’t have to deploy Windows—more expensive and heavy Windows hosting environments—

Derek Dysart:
Sure.

Alex Shyba:
—for your production for the app tier. Still need those for Sitecore content delivery endpoints—

Derek Dysart:
Right.

Alex Shyba:
—but you have total flexibility there so what I showed instead of doing the Node.js route, which has kind of been done before—I deployed the app to CDN—

Derek Dysart:
Okay.

Alex Shyba:
—so this way you have browsers doing the rendering of output, JSON output from Sitecore, along with the bundle—your JavaScript. Then you get HTML rendered by the client.

Derek Dysart:
Okay.

Alex Shyba:
So by using some of the cutting-edge CDNs—we like using Netlify a lot for any of the web stuff—so they have a cool drag and drop from a folder from your desktop into the browser—

Derek Dysart:
Okay.

Alex Shyba:
—so without even setting up an account you can do these anonymous drop and deploys.

Derek Dysart:
Yup.

Alex Shyba:
And then it will take the folder with your JavaScript output and it will deploy it to, you know, 30 whatever locations globally in seconds, right?

Derek Dysart:
Sure, sure.

Alex Shyba:
[laughs] That’s a pretty different way of deploying your app. I had Sitecore deployed into Azure Pass, and that was my headless endpoint, and the app went to CDN.

Derek Dysart:
Okay.

Alex Shyba:
That was kind of one way of doing it with content, running a connected app on the CDN, the browser connecting to you, CDN endpoints for content, and then to kind of dial it up to 11, I showed a way to publish content into CDN as well—

Derek Dysart:
Okay.

Alex Shyba:
—so if you want to detach from content delivery and cache all of the app content into it, we have a little module we built that lets you publish to Netlify.

Derek Dysart:
Okay.

Alex Shyba:
That means you really use Sitecore CDs only for personalized content—

Derek Dysart:
Yeah.

Alex Shyba:
—and for anything you want to query, run a complex query. I want to query my product catalog. You don’t want to pre-publish a whole product catalog and query to the client. You cannot even do that, so this way you have—you split what’s your static portion of your web content, part of your kind of page model—

Derek Dysart:
Okay.

Alex Shyba:
—and what’s kind of dynamic, what’s contextual. With JSS you can marry kind of the two approaches because there is a way to render not just full page but part of the page so only that part, that zone that is personalized, so it gives the ability of the app to do—kind of meld the two worlds of static content and dynamic content delivery.

Derek Dysart:
Yeah, so you’re—I mean, you’re caching all the “static content.” You know, it’s still content managed through the content management system—

Alex Shyba:
Yeah.

Derek Dysart:
—but it changes infrequently, so that gets pushed out to the CD on, and then the stuff that does change or needs to change due to personalization is sent back to Sitecore and runs the personalization. That’s pretty slick. So I think—you know, this was obviously—you did this as a demo for a kind of show proof of concept, but talk a little about, like, if this was an actual production app. I mean, really from a time-to-market standpoint this seems like a whole lot—I mean, you did this in the course of a 40-minute presentation, but, you know—from, you know, scaling this out to a, you know, a more realistic project, you know, maybe you could talk a little bit about, you know, the speed that this gives you as a developer for deploying this app.

Alex Shyba:
Yeah, I think there are two aspects here. One is speed of prototyping and ability to just knock a few things out if you want to build and experimenting with your, you know, VP of marketing or whoever wanted to launch something new, interesting, and paying an app, you can do that without paying the CMS integration tax—

Derek Dysart:
Yeah.

Alex Shyba:
—so build it out completely stand-alone and then either hand it off to a CMS developer for integration or script the integration to make it fully automated. So get from kind of ideation to real functioning prototype that is already prepped for CMS integration very, very fast. So that’s kind of experimentation acceleration and other pieces, just day-to-day faster deployment, less—yeah, less taxing updates to your existing digital property.

Derek Dysart:
Yes.

Alex Shyba:
Because of this decoupling from CMS, you—if you need to, you know, do a buck fix, let’s say, that code doesn’t touch content. You can deploy it without going through CMS deployment completely because—

Derek Dysart:
Sure.

Alex Shyba:
—app tier is completely separate. It lets you redesign your digital property potentially without any changes to CMS—

Derek Dysart:
Sure.

Alex Shyba:
—which is kind of close to impossible to imagine with coupled systems.

Derek Dysart:
Yeah. Any CMS, Sitecore or otherwise, it’s, you know, kind of a heavier move. And I think, going back to, you know, when you were talking, you can leverage tools like React Studio to rapidly prototype something. Now you’ve also got the ability where you don’t have to have a developer fully steeped in Sitecore and knowing that—you know, there’s—it seems like as you do the integration part and pull in the Sitecore pieces, you can use somebody that’s, you know, just a solid front-end developer that knows their—you know, knows React or knows Angular or knows Vue to rapidly prototype something out. They don’t even need—they can do it on the system they’re used to. They’re not having to fire up Visual Studio and learn how to write Razor views.

Alex Shyba:
It’s so amazing to see when I’m doing these boot camps it’s usually three front-end developers and one back-end developer. It changes the team structure, and when I see how it starts clicking with front enders—they’re like, oh, yeah, that makes sense—it’s just so much different than traditionally trying to bring a front-ender into, you know, a .NET MVC environment. It’s just too foreign and it’s not—too many obstacles to overcome from a tooling perspective environment, right? So it’s awesome to see when it kind of clicks and it just makes sense and lets them work the way they want to work. And JSS doesn’t change the way they—doesn’t introduce, you know, brand new developer workflow. They can use their own stack. It’s kind of just augments their stack instead of kind of reinventing and coming up with its own build system tooling and enforcing something that shouldn’t be enforced. So it’s a very unobtrusive way to bring front-end devs into the fold and into the Sitecore ecosystem and have specialization. You don’t have to have, like, somebody doing pipeline back-end customizations and then coding up Razor views the second day.

Derek Dysart:
Yeah.

Alex Shyba:
And specialization project managers love it. It just makes sense, and that gives you that two-speed kind of—two-speed delivery. And probably what’s most important is the output of front enders’ work will not be then interpreted and coded up in CMS templates like in Razor views. It’s the same code that they produce. That’s what runs in production.

Derek Dysart:
Yeah.

Alex Shyba:
So you eliminate that kind of additional effort of interpreting front-end deliverables—

Derek Dysart:
Yeah, yeah.

Alex Shyba:
—in CMS.

Derek Dysart:
Yeah, there’s always that translation from, you know, say, the HTML cosw that front-end developer does, and that’s got to get sliced into, you know, into pieces that go into the CMS, so that’s interesting. I think the other point you touched on that I find interesting too is there are a lot of—you know, you mentioned Netlify. There are a lot of services out there for deploying these applications in a highly scalable way that now open up the door for a Sitecore back-ended site to leverage that.

Alex Shyba:
Yeah, it’s a real pleasure to work with these tools. It’s—and so refreshing often. Things are much more lightweight. I was using macOS during my developer demo—

Derek Dysart:
Uh huh.

Alex Shyba:
—at Sitecore Symposium.

Derek Dysart:
Yeah.

Alex Shyba:
[laughs] So that was kind of risky, right? I couldn’t even get the projector to work for the first couple of minutes, so that was intense. So being able to show how you can be productive on a Sitecore build on a Mac—

Derek Dysart:
Yeah.

Alex Shyba:
—you know, that’s fairly new.

Derek Dysart:
Yeah, that’s definitely new. That’s definitely new.

Derek Dysart:
Well, Alex, I appreciate—

Alex Shyba:
[laughs] Shouldn’t be.

Derek Dysart:
Yeah, no, it shouldn’t be but yeah. So, Alex, I appreciate you taking the time today. If folks want to learn more about you, where can they find you online?

Alex Shyba:
I’m occasionally on Twitter [laughs] at @alexshyba.

Derek Dysart:
You are.

Alex Shyba:
Or hit me up on LinkedIn.

Derek Dysart:
Great, great.

Alex Shyba:
Yeah, I’d love to talk. We’re going to be doing boot camps this fall around November, December, mostly around big US cities, so it’s an opportunity to learn more about JSS and have a two-day immersive experience—

Derek Dysart:
Great, well—

Alex Shyba:
—with me so—

Derek Dysart:
We’ll stay tuned for that.

Alex Shyba:
Yeah.

Derek Dysart:
Yeah, thanks again for hanging out and talking a little bit about headless CMS.

Alex Shyba:
No, it’s a pleasure. Thanks, Derek.

Find begivenheder i nærheden

Brug min aktuelle placering

Skift min placering

Anvend