See full event listing

Best of Both Worlds: Combining a headless CMS and Jamstack

This talk addresses how the software architecture, Jamstack can be used along with Headless CMS tools to provide a better and simpler developer experience and how the combination of JAMStack and Headless CMS makes it easier to deliver and manage content securely.

Ifeoma is a frontend Engineer with experiences that include Developer community management and developer education, she enjoys talking about topics related to the frontend and web performance.

She is also strongly interested in advocating for women in technology and this has brought her to volunteer as the Chapter Lead for Frontend Foxes Nigeria for the past two years and volunteer as a mentor for two different tracks with She Code Africa. Currently, she also serves as a Developer Educator at the Frontend Foxes Bootcamp.

When not working full-time, she is either reading, drawing mandalas or wondering if color orange was named after the fruit or the fruit orange was named after the color orange.

Transcript

Ifeoma Nwosu: [00:00:00] Hello everyone. I’m Ifeoma front and software engineer and a developer relations engineer. I have experiences with developer education and helper, community management, and at the jam dev I will be speaking on this combination of headless CMS and JAMstack. In this course, I will be address. , the benefits of making use of headless CMS and the jam stack architecture.

Now let’s roll you back a bit. Before we had the jam stack, there were a couple of other stacks that were really popular. We had the LAMP stack acronym for linox ache, she My Skill and php, and we also have the MEAN Stack, an acronym for MongoDB ExpressJS. , Angular.js and Node.Js. [00:01:00] The JAM in Jamstack stands for JavaScripts api and markup.

Now, if we have to take it back a bit when websites will not a bit, actually take it all the way back, how websites looked like much earlier when websites were being created. It was really simple. If you. Have a look at, if you could visit really old websites, you’d see they were mostly made up of just text.

That is the front end the we’re made up of just hit text, which is the html, and it was really simple creating websites like this. It did not take much, but as time went on, more content had to be served. Banking technology became advanced and we. We make still use of a lot more like servers, databases, and there’s a lot more stuff going on in the backend.

And whenever webpages or websites, web applications had to be created, even if we were just two page web applications, you would take a lot in [00:02:00] just running these website. It would like, performance would usually get affected, and so to resolve this CMSs were created, all traditional CMSs as we now know.

Then examples. Really popular, traditional cs. We have WordPress, Drupal, and Joomla. Now this came with a benefit. The most popular benefit that comes with traditional CS is the ease of use. You do not have to be a technical person to make use of traditional cs. It became really easy to change content, make changes to your to website, but they came with a couple of cons and.

we had poor performances because a lot of these CMSs to extend functionality, we make it of what is known as plugins. Plugins are usually used in CMSs to extend functionality or to add more functionality to them and more plugins being added. And like you’d want your website to have more functionality, you have to add more plugins and more [00:03:00] plugins, which are being added.

That would also result in poor. And this would usually result in errors. Sometimes there would be errors from a lot of these plugins being would clash, like clashing, like code. And this would also result in, if you are very popular, if you are very familiar with WordPress, you’d be very familiar with the very popular error you’d be very familiar with, excuse me, when common error known as the white screen of death and.

These CS method of VE coding languages, usually on the back end, if you are not a very, if you are very conversant in this languages, it’ll take you some time before you image of those cms. It’s going to take you time before you images of that cause you’d have to pick up the language or you would not be able to use that sames at all.

One of the very major cons with this, That the front end layer was tightly coed to the backend layer. And so that mean the front end layer was not [00:04:00] independent of the backend layer. Whatever it was that was happening, there was a downtime on the backend. It would affect the front end if the front end could not just exist without the backend.

And this would usually result in engineers not being able to, or developers not being able to make use of the front end languages they would want to make. When creating the presentational layer or that, or the front end layer. And so it did come with a couple of solutions. It did at that time traditional services did come with a couple of solutions.

Ease of use. Yes. But they did lack flexibility. And because of these issues, we were able to have headless cms and. The differences between headless CMSs and traditional CMS is that the headless CMS comes with a decoupled front end layer, and that makes it possible for engineers to be able to make use of whatever [00:05:00] language they would want to make use of on the front end.

Whatever happens on the back end, whatever happens to the server side, it’s independent of whatever happens on the front end. for content to get displayed and API is being served. And this API gets consumed by developers to be able to display content, self content. And this made it a lot more easier. This also really improved performance, and of course, because of the decoupled front end layer there was a choice to be able to make of whatever language you’d want to make yourself, whatever framework you’d want to make yourself instead of just making use.

The language that came with that cms or the language that came with that same as traditional cms. Because of all of this prose, it became really good to use or it became good as just mentions with make use of healthier CMS and the jam stack. And we CS Jump and hes [00:06:00] match made in Developer Haven.

And that is because it made things really easy for engineers and software developers, workflow became really easier. And here I have an illustration of the database and the API just being serves to the front end, all of them being independent. But api, the API data from API being served to the front.

The benefits of making use of he CMS and JAMstack is that provides a better software architecture and it’s scalable because of its normal monolithic architecture. And this is to say that when the back, because the backend and the front end are not tightly or presentational layer, whenever there’s an issue at the back end, it does not affect the front end.

And if. Recall my example of a con making use of traditional CMSs where whenever there was an issue [00:07:00] from on the backend, it would always, and we try to visit the websites created. For example, it is popular cms, for example, WordPress. You would see a white screen, nothing being displayed, but we tell less CMSs for.

He WebPress also has its own headless cms. And so for you to be able to make use of the make use of a web, a webpage, this would. , this arrows going on the backend also affect the front end, but with traditional with, to say he, cms, this does not occur. There’s also the ease of flexibility, and this is because you can be able to pick whatever languages you want to use on your backend or your front end, whatever it is.

The paralyzed in the hands of the software developer. There’s also a be, there was also a, there’s also a better work. being treated when you make use of headless CMS and JAMstack. Non-developers can make use of, can manage content on the headless CMSs. This [00:08:00] is one of the reason why I really like the combination of JAMstack and headless cms.

The first fact that the developer comes in creates the web application. , a non-technical person, eh, probably the content manager, the person who manages content on the application can make, can manipulate the contents, change content from the headless cm. They do not have any business going into the code base because they’re non-technical anyway and the developer does not always have to come in with.

Content needs to be changed. Unlike traditional services where there’s a downtime and issue. So the developer only comes in when they are absolutely needed. There’s also enhanced security, and this is because of the separation of the back end and the front end, and well more collaboration on the path of past really popular [00:09:00] Jamstack.

Examples we have next. , which is based off next, based off you and Cat B, which is also based off React. And we also have really popular headless cms, the sanity butter CMS Contentful and Storyblok. Now all of these CMSs do serve their contents making use of the REST API and this and REST API consume and REST API gets consum.

provides of APIs to be consumed. And this gets consumed by in the application, in the jam stack, in the jam stack jam Stack tool. For example, NJS or not js. And when this. Content is created in the HE cms, and it also serves this content in form of an api, which gets consumed on by the Jumpstart tool.

Could be Next.js or Node.Js. For example, if you’re making use of Storyblok, you [00:10:00] create your contents in Story Block, get API yourself to you by on Story block and this. Consumed by your next guest application and you get, your content gets displayed on the front end, thanks to the API and this is, and that is you do not have to, so one of the benefits while this is very popular for Jumpstart applications to be used alone, one of the very popular reasons I.

Say why it’s a benefit to make use of headless cms and JAMstack is almost for issues, for reasons relating to security and for better workflow, most of all for better workflow because it makes it easy for the, for developers to create this application and then when if the content needs to be changed or worked on, there does not need to be, there doesn’t have to be so much back and forth.

Whatever needs to be changed or whatever needs to be worked on can be done from the headless ceiling. This [00:11:00] is. and this, and another very good reason why we have this the makings of s and jamat is the re, is the fact that the backend gets separated. A lot of jumpstarts will also come with without have their own backend and everything they cater to, they’re running and the surface and everything.

So what has to be catered with just the presentation earlier. And so this is why I. Strongly suggest making use of a he CMS and a jam stack. And this combination is usually suggested for businesses businesses where web application contents is always changed in the applications making use of headless and JAMstack is as a.

We making of the super combination of headless Service and Jamstack is strongly suggested for applications where content is always being changed. Thank [00:12:00] you for coming to my talk, and if you’d like to reach out to me or maybe even ask questions, please say hi to me on Twitter. I’m always on Twitter at my personal Twitter account.

Thank you.

More Awesome Sessions