Transcript

Note: The following is the transcription of the video produced by an automated transcription system.

Hey, guys, thank you for watching this video today we have myself, which is Akshay Sura and Kamruz. We are hoping to show you a demo and a use case for Content Hub As a Service. We have our colleague Harrison, who helped us out a little bit with Next.js and React. So we are we’ve been talking about Headless CMS’s for quite a while, and we have been playing around with these headless CMS’s and seeing how we can utilize frameworks like Gatsby and Next.js and hopefully push them out to anyone who can really host a static site or a Node based site. In this case, you name it, there’s a ton of providers for it. Yeah, these JAMStack based technology sets are obviously very, very popular at the moment due to various reasons, ease of development. There’s multiple choices of CMS’s and you’re able to plug and play the entire stack exactly what you have, what you need and exactly how you need it. And you can extend functionality using various bits of serverless type technology stacks over in Azure, AWS or even nullify itself with some of the new features that they’ve been introducing. It really is quite an interesting technology stack, particularly for us long time developers who have been very much server based and dot net based.

It’s interesting to see the technology stack almost go full circle back to raw HTML CSS and JavaScript. But for this demo we just wanted to put together a few bits of technology that we’re being quite familiar with. And which brings us on to Content Hub, of course, and the other thing, you mentioned cameras to the Serverless as opposed to having sorry the server side rendering, as opposed to having static site generation having both capabilities right like from a capability perspective. We could have server side renderings to those dynamic things and host the site that way, or for most cases something like a site like Konabos.com, we could just get away with it just with a static set generation. Yeah, exactly, so these frameworks such as Gatsby and Next are pretty good in that regard because they allow us to generate static site if we wanted to, or running in server side mode. If we actually need to have some processing and processing happening on the server side for whatever process, whatever backend systems we need to integrate with you. Obviously, Gatsby and Next are JavaScript based and reactivates in this particular instance. So it’s still not for our main skill set in terms of dot net. But, you know, these skills are transferable nonetheless. Yep. All right. That brings us to our use case, which is what we wanted to try and do. I know Sitecore Content Hub isn’t a headless CMS, but we wanted to see if we are able to produce content in Content Hub, use Content Hub as a service, do some magic in terms of hooking it up to the right pipeline, setting the right workflows and be able to push that piece of content, utilize framework like Next.js in this case, pull the information and then push those, push a static site out to Netlify and see if we are able to do that. That’s basically was our use case for us to do so.

What we wanted to do was create a demo site, a fairly rudimentary basic site in this particular case, but have some of the content driven from content hub and have these pages, the data for these pages coming from content hub and created as as we add more content in the sample blog app for example. So for this, what we did is in our Content Hub instance, we created a new CMP type called as Web page. In that type we’re taking basic information, which is the title and the content in it. What we are hoping to do with that is we are hoping to run a trigger. This trigger is going to run when a particular piece of content which is M.Content in this case gets modified and then we go to ready to publish more than when that happens, we want to be able to call in action. The action itself calls a Netlify web hook, essentially, and that Web hook will trigger a new deploy to the, you know, to the static site because we needed a way for us to be able to modify content and for the content to be able to show up on the website. So we need it to generate this static site again. And bear in mind that these builds are not taking 10, 15 minutes. They’re sub one minute build’s. So we were able to set up these hooks in place so that we are able to get the content across when we needed it. So before we go through adding another thing, Kamruz is going to walk us through how we set up the Netlify, the Netlify set up itself. If you guys haven’t used that before, it’s super simple to set up. It’s you can have a free tier to start playing with it. But for the deployment itself, I have a repository set up with our JavaScript and next JS code with the calls out to the content hub API. We so we have a repository set up. We have our build command just to build the solution to push it out.

And we then have a built hook created, which is the trigger we call from content hub itself. There’s two parts to the build. There’s the code changes. So if we make any tweaks, changes to our code, check that into GitHub, that will automatically trigger a build into our production instance. Whatever that is, whenever there’s change to the master branch, then then the second part to this, of course, is content. So whenever we update some content in content hub or we add some new content, we need to trigger a build because we don’t have the equivalent of a publish in as we would, we Sitecore, for example. So we’re using this built hook in this case for it to some Content Hub calls into this build hook that help build hook will trigger the build, which will in turn build the code and then fetch the content and the pages from content hub itself. As Akshay mentioned, they are super quick now. We have sub one minute builds for the entire site, including deployment. So we can we can run through this process to show you how the edits works and the creation of a new sample page works as well. Ok, for the next part, what we will try doing. As you can see, we have our site currently. We only have two pages, which is about as an Konabosing we’ll go ahead and create a new piece of content. Let’s call it demo. This needs to be of type web, page it OK, to go out and create the ones that created. Lets edit it. That some sample content. And let’s push it through the workflow, so what we should see is. Once we push it to the ready to publish workflow, so at this moment in time, we don’t have the new page, we don’t have a deploy, which is kicked out today. And once we hit approve, what is going to happen is this piece of content goes into the ready to publish state. Also, if we take a look over here in terms of audit logs when I’m waiting for this specific trigger to trigger. So what happens from a content perspective is it gets created as a job in the background because this process of triggering the web happens as a background process. So it will go through that hopefully takes a little bit of time because ours is a test instance and one that once that happens, hopefully it should trigger a build, which it did. And if we’re going here. And while that’s still building, we don’t have the new page, obviously, but we just wanted to show you and then let them know that it will do its job.

And we have built complete and as you can see, we have the demo page up and these pages are super fast, as you can see. And again, we’re not even on a production instance, but they just go through extremely fast. And this is something which is super important, especially when it comes to the amount of money you spend on your infrastructure, which makes a big deal and also how fast it is. And one of the things which gets touted as the benefit for these headless masses is that the marketing department or anyone who is actually building these sites have the capability to build the site using whatever they need to, but have a central store. In this case, we’re using Content Hub. But in another case, it could be another headless provider where the content is getting stored in a structured manner. And then pretty much, I would say the biggest hurdle Kamruz and I faced was mainly not having that much experience with this Next.js. But once we got into it with Harrison’s help a little bit, it got a little bit easier. And towards the end we were able to modify things ourselves. And it’s just like the Kamruz said, it’s the skills are transferable. But coming from a totally backend programmers perspective, all of a sudden switching over to the JAMStack might seem like a bit too much, but once you start getting into it, it gets easier. As definitely an interesting stack, and it was interesting to play around with it using Sitecore Content Hub because that isn’t a headless CMS as such. But the API is it has an API available. It has an SDK available as well. So that made it a little bit easier. It is obviously missing some of the nice functionality that you’d expect from a headless CMS, things like caching of content, availability of a graphql Web point. One of those things I think would have made it would make it easier in a production and an actual production build, but it’s definitely capable of being able to build out an entire site, not just the main content body like we had done here, but with I think with a bit of smart thinking, you could do entire sites like the headers and the footers and that kind of stuff, as well as being able to and some of the triggers and the actions within content hub does also make it a nice way to do other custom things in the background if you needed to. So obviously we’ve just got a very simple trigger to kick off a build and a deployment. But you could hook that into all sorts of other systems, such as, uh, indexing, for example.

Yeah. All right. Thank you so much for joining us for this video. Hope it’s useful to look forward to many more JAMStack based videos coming up shortly. Have a wonderful day. Thanks, guys.

If you have any questions, please get in touch with me. @akshaysura13 on twitter or on Slack.