In this video we are going to go through how we used Sitecore Content Hub As a Service and push content using Next.js to a static site on Netlify.
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.
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.