Building Modern CMS Driven Web Applications with Strapi the OSS Headless CMS

And welcome to React Advance! This is a workshop. Today we'll be talking about building modern CMS driven web applications. If you've used the CMS, let me know in the chat, if you haven't. to you have about CMSs. This is the whole thing that a lot of people talk about, a lot of people aren't too sure. So feel free to put that in the chat.

And a little bit about myself, can see. Reebok myself, I'm Daniel Nirmala Madalisa Piri and you can groots there we go. Yeah, I'm Daniel Madalisa Piri. And you can touch me almost anywhere online as MaoGamers, to developer relations and a company called Strapi, which is a open-source JavaScript headless CMS. And I'm a disc jockey at Mixcloud, I guess. I don't know if you can sort of call it a thing, it's not like an official thing. But anyways, I teach a technical and I put my stuff up on Mixcloud basically.

A few prerequisites before we get into the meat of everything. You need some basic React knowledge, as would be using nxtjs to sort of build our blog. Basic knowledge of Node and NPM, of course, and basic web concepts, and some knowledge of APIs. Okay, I'm just checking chat. I see a lot of people or a couple people have said what they use graph CMS wordpress on Adobe Experience Manager. Both as headless solutions. That's interesting.

And all right. So let's let's get into what we'll be looking at today. We'll be looking at an intro to headless. And then we'll be setting up Strapi and Next.js. Give you a nice introduction to Strapi and Next.js if you're not familiar with it. And then we'll go out and build a blog. And we'll look at how we can deploy our apps. And fingers crossed, there's a bonus section. So you should be looking forward to that. And has anyone used Strapi in the past? Has anyone used Next.js? Before I get into the intro? Yes or no, we do? No, okay. That's exciting. Okay, because a lot of people who will be so maybe you should just make this a Strapi workshop. Anyways, an intro to headless a lot of people seem like they are aware of the concept of headless at least. So let's get into that. I always like to set like a nice preface to how things worked in the past. So, someone already mentioned the CMS like WordPress, which is even though it has like a headless solution in the past was a, was solely a monolithic and these are the CMS as we call traditional CMSs. And it had a back office, which is basically an interface where you manage your content. As the name suggests, CMS is short for content management system. And then you had a front office where you manage your web pages. And the thing about that was you're only able to deliver your you know, these web pages to one platform, and that was the web. And you interact with that on usually laptops, computers, and all other devices that can have browsers. And they didn't really support native mobile applications can support, you know, wearables and it was really hard to connect to different platforms outside of the web with these monolithic CMS. So the world changed. Of course, as you can see, today, a lot of how we interact and engage is on mobile. Still a lot of the web, but that's because CMS has had to evolve how people manage that distribute content had to evolve. So we had to stray away from the whole concept of tightly coupling the back office and the front office where you can only manage content for a single platform. It didn't really make sense. And front end tooling evolved. I see a lot of people here are really into Next.js, which is super hot for a lot of reasons. And, yeah, front end tooling evolved. We had tools like react come up, and a lot of these other tools. And traditional CMSs didn't really suit them. And CMSs had to evolve not just for different platforms, but also for the web. So why CMS? This is sort of like an argument I like to give for why people use CMSs. I believe and I feel like a lot of people would agree with me when I say building software is a collaborative effort of multiple teams. So a lot of people come together to sort of make software happen and ship products, ship features, ship websites, ship apps. It's a collaborative effort, right? So who's involved? The most, at least, active players I see in this are developers, designers, and content managers. At the intersection of all of these, we sort of see headless come. And how, you ask? Good question. So you have developers, of course, who build with the headless CMS, depending on your capability or the capabilities of your headless CMS, you can have developers use that. With headless CMS, you introduce the concept of content modeling, which I will get to really, really soon. And what that enables is you to sort of break down your website into components, per se, or different smaller building blocks that make up larger sort of bundles. And that really helps with design because you have a content-first driven approach, where you look at the content you want, that dictates what designs you make, the designs dictate what's developed. And it all starts with content. And then of course content managers, people who use your headless CMS. Headless CMS of course delivers content, but who puts data in there? It's the content manager. So there's a lot of people involved with making sure that things work as they're supposed to work. And that's exactly what Headless does. So Headless means we deliver content to any front-end via an API, any front-end with an asterisk there because this is most different things that can consume APIs or make HTTP calls, and that's what it enables. So you have a single platform where you edit or you enter your content and then that ships it out to mobile, ships it out to the web, ships out servers to wearables, and that's the benefit of headless at least.

With headless now you have a back office and an interface to manage content. Now you can send that to a lot of the popular frameworks. You can send it to Flutter, you can send it to Swift, you can send it to a lot of the other things people use and it makes it pretty versatile because you can send it to multiple platforms all from a single source. And this brings a lot of really cool benefits. It's a much more secure business solution in terms of future proofing your stack also. You can use a headless CMS if things change front-end wise, people really aren't using Next anymore, or people start using something new like, I don't know, Astro or Sword Kit. You're sort of secure in the fact that your back-end can stay untouched, and you can just adapt your front-end to suit what's trending, if that's the thing you want to do. Or what's solving your problems in a much more efficient way. You can also create custom experiences like I talked about, and all the workflows that can be enabled through using headless CMSs really do a lot to improve your team's philosophy, so it's a lot of benefits.

The quick recap. I don't know if you have any questions about concept of headless or what headless is. And I feel like we can we can get into using strappy and next year. So move on in like a minute. And if you have any questions, then we can go ahead.

Right, so setting up. strappy and next yes. So I'm going to open it up. I have my eyes on the chat by the way, keeping track of that. Okay. So we'll go into my terminal. Thank you. Let me just grab my chair. Real quick it's like. All right now I'm ready to type. And I'm going to try to write code. All right. So setting up Strapi. Like I mentioned, Strapi is an open source headless CMS. But before we do anything actually, I'll just exit this and just go directly to like strapi.io for those who haven't seen it. So, this is Strapi. Pardon the slow load. I'm using my phone because my wifi is down. Thank you Bruce. But yeah, this is Strapi.io. Design API's fast, manage content easily. Open source, 100% JavaScript. Fully customizable and developer first. And how we get started with Strapi is, open up terminal and we'll type, let me change that exactly. And, advanced. And, React. Let me know if I should zoom in. Let me just do that preemptively. That looks kinda small. Okay, so the command, you can either use yarn or npx to create a Strapi app. And what this will do is, let's just call this my back end actually, or a block, cause that's sort of what we're making. And we'll use the quickstart flag.

So, a bit about Strapi, while this command is running. And we'll just, sorry. Yeah, anyway. I was looking at the chat. Yeah, a bit about Strapi and why this command is sort of important. You'll notice the quickstart flag. So Strapi, like most CMS's needs to store its data somewhere, and Strapi supports multiple databases. At the moment we're using v3 of Strapi and this will either, if we didn't use the quickstart, it would query us to, like, choose our database. We could choose from Postgres, SQLite, MySQL and MariaDB. And yeah, that's sort of what we used to set up the Strapi project. Now setting up a database for most can be quite daunting. So when we use the quickstart flag, what that does is it defaults Strapi to use a SQLite database, which is much easier to set up. And when you go into production, of course, you want to go into something more resilient, such as Postgres. And you can do that for free on something like Heroku or, like, free AWS tier. Yeah, so besides that, like I said, because we're running this locally at some point we'll have to deploy it. So Stripey is self hosted and we currently don't have a cloud offering and that is probably coming sometime soon. And yeah, I don't know if you have any questions about the setup so far. Once this happens, we'll sort of like dive through everything. Well, I should've accounted for, but this setup might take time just because I'm not using yarn, it's not batched and might take some time for everything to download. And yeah, anyway the good time for you to ask questions should you have any. I'll just check the discord real quick. And thanks Bruce for sending over the commands. So before we actually get started building the blog, we'll just play around with Strapi and I'll show you all the cool stuff it can do. And yeah, let's see how that goes.

So like I mentioned, usually have a back office. What's happening right now is we're building out the admin panel, which is the portion of Strapi that content managers and we sometimes get to interact with. And this is built with React also, it's fairly customizable because it's open source, we've seen a lot of people change, a lot of things about this and people change the whizzy wig, people change a bunch of stuff actually, the theming, the coloring, and you can just deploy one thing so. Just give me a minute. There we go, so there we go. We're redirected to localhost 1337 and then we're asked to enter a new admin user, so I'll just enter my own details here. Dip, dip, dip, dip, dip and quick password. So the passwords are the same. The password is bothering me and then here we are.

Let me just zoom in a bit. This is our admin panel. So this is what you see when you first get into Strapi. We have an admin user called Daniel Piri that we just created and now we get to build collection types.

So CMSs, like I mentioned, have the concept, headless CMSs have the concept of content modeling which is just creating like a data schema for how you want your data to be presented to your front end. In our case, we have what we call components, which I think would make a lot of sense because they're based on the components that we all know and these are just reusable sections. So these are a collection of fields that are reusable in multiple, multiple places. We have what we call collection types which are repeatable collection of fields. And then we have single types which are one use collections for fields.

So let's go ahead and build out our first content type. And we want this to be a collection type. One that I usually find very relatable is books. So we'll create a collection type called books. And what Strapi does and that's something that I really like is each collection type you create, you have a corresponding endpoint. So when we're done creating these collection types and we want to query the books endpoint, all we have to do is go to our URL. If this is localhost, that's localhost 1337, splash books, and then we'll be able to retrieve all the entries on that endpoint. Which is pretty cool.

So yeah, these are the fields that you can pick out. You have the text field, rich text field, a number field, a date boolean relation. The relation is really cool because it has polymorphic relations. Sorry, you have email, you have password enum, media for videos, links, audio, a JSON field and a UID field. And then these are the components that I talked about. And then we have what we call dynamic zones, which is a really, really interesting feature of Strapi that lets you dynamically add components to an entry and paired with like a lot of, like some magic or I don't want to call it magic because it's a bit of a word, paired with some like creative programming, you can sort of create some very interesting turnarounds and workflows. We've seen people create like forms or like page builders, like no code page builders where you have a bunch of components Strapi and these are matched to a bunch of components in your front end. And then by adding new pages in Strapi and using the dynamic zones, you can sort of build out pages in your front end, which is pretty cool. But yeah, let me keep demonstrating books and let's think about what a book's end point would look like or what books, what type of fields a book would need. I think a book could need a title, very important. A book would need an author, and one thing we have a chance of doing here, but I won't, is we could create another collection type called author, and then form a relation. And these are the relations that I talked about. Hey, are you asking me a question? I heard someone say something. Nevermind, okay. Yeah, as I was saying, one really cool thing we could do is we could make it so that, if we had an author field, or let's say user, and let's just, this is the Vennus letter, and what we could make it say is that every book could be there related to, maybe that's not the best one. But anyway, yeah, one could either be related to one, they could be related to each other. One book could be related to multiple authors, multiple books to one author, many to many, and all these really cool relations. So yeah, I think the relation field is pretty cool. So besides title, what else could we need, maybe like number of pages, number of pages, page, number. No, number of pages doesn't make sense. And then format, we have really interesting, I think page numbers are usually integer. Oops. That window doesn't look the best. And we'll add another field, and maybe cover. Let's see, cover, cover is usually like a single thing. It's like a picture. It's not necessarily multiple files. So once you've sort of created this, that is this supposed to be a page. Great, so we saved that into like a schema.json. I saw a question. Okay, well, the server is restarting. Let me look at that. Yeah, that is possible. So someone asked if it's possible to populate the different collection types that we could create in Strapi from a dataset like a CSV or a spreadsheet. We have seen that work. You can sort of create custom scripts that can fetch that data from whatever it is, a CSV or a spreadsheet, a markdown file, or a couple of markdown files, and then send that into the Strapi database. This would have to be custom, of course, but yes, it is possible. Great. So we have our books collection type here. And now we can start to enter data. So I don't know. What books do people read? Let me look at my shelf. It's quiet. Oh, number of pages. Then we could actually pick something. I don't know if I have images. Do I have any images that I can pick up? Ah, nice. It's just like random pictures that I have, and we'll upload that. And then one really cool thing we have also is we have a draft and publish feature of course, which is, the events have that. So right now our content is in the draft mode. And then if we want to publish that, so it's visible now we have a published piece. Okay, so now we have one entry, you can see this and then you can see the number of pages and then you have a cover. That's pretty cool.

We'll add one more just for, another, or read books, there's like zero to one, I guess, open a book, a short book, maybe about 90 pages. We'll add the same cover. We'll save, we'll publish. And now this is sort of where it gets interesting.

So we can navigate back to our collection types. And I just want to make another one just so you can see the different types of collection, the different types of content types Strapi has. So right now we're looking at a collection type, which has multiple entries on a single, on a single collection type.

Another thing we have, if we go to our content types builder is the ability to create single types. So single types here would be used in a scenario where maybe you're a publisher in the house and you have a portfolio maybe, maybe that's a great example. I think the best example I can think of for the use of a single type is a website homepage. So we can call this homepage, but this is data that you only need in a single instance. Yeah, so I see someone has an issue, Matthew. Could you give me more context about your device, your Node version? One thing that I find helps is if you refresh, sometimes it could just be nothing and it's computers being computers, but that indeed is very strange. Try and refresh and I think your error should be fixed. All right.

So back to the single type. So we built it out like a normal collection content type. And let's say our homepage needs like a fabric on a logo. That's content that we only need once into the single media. We need like a page title. And what else what we need. We may need some metadata. But yeah, we could probably create a component for that. But that's basically it to be honest. That's what single types are used. So I've seen people use single types for navigation pages where you don't need multiple instances of navigation pages. So when you come and look at this and you want to enter data, you can only enter this data once. And unlike the books where you have multiple entries with single types, you only have this single instance. And it can be very useful. We sort of use that internally at Strapi for a couple of the functionality on our website. So we can go ahead and edit this also. And now we can say, the title, our lovely homepage, something like that. We work at popular and we'll save this and publish it. And there we go. One instance of our single type. But let's get back to our books API. Let's query that. Let me just sip some water. Okay. Back, back, back. Yeah. Let's get back to our books. Oh yeah. I just seen the chat. I'm feeling glad the error is fixed. If anyone else has an issue or if there is anything that you'd love to troubleshoot, like send a message and we can get you through it. Great. So now let's get back to this. I've run you through collection types, single types. And then we have a couple of plugins. Plugins are pretty big for Strapi at the moment and will be getting much, much bigger. We have the content types builder which helps us build out our sort of content schemas like we just did. We have the media library which helps us manage media, of course. I think we have like a tiny but soon to be much bigger marketplace. And where we have a couple of different plugins, we have a GraphQL plugin which gives Strapi GraphQL support, and you can run a lot of graphical operations, queries mutations, and GraphQL works pretty well with Strapi. You have a documentation plugin to get like a Swagger documentation, like Swagger UI for each of the collection types you build because at the end of the day, like I mentioned, all your collection types become endpoints. So you can document your Strapi API by using the documentation plugin. We've got like a really rich third-party ecosystem of plugins in this repo called awesome-strapi, which I will send into the discord and here, if you wanna have a look. And this sort of solves a lot of really interesting problems that people have for a lot of plugins. So we have a lot of starters for Next.js for example. We have like exponent notifications, most of site maps and different wizzy wigs, editors community hooks, email providers, upload providers, different SDKs. Anyway, I think you get it. We've got like some really interesting plugins and then sneak peek something that's coming up. And I'll talk about this a little bit more at the end. Scrappy will be launching a plugin marketplace pretty soon. So let's go there. So a new way to make Scrappy awesome, coming soon. And we'll have a lot of really interesting plugins built from some really interesting people. Okay, so back to that. So we've seen our marketplace and then we have a section here where we can see all the plugins that are installed to our Scrappy.

Plugins can be installed either visually clicking buttons or via the command line inside the Strapi app directory. You can add internationalization and unlimited locales. Strapi comes with the P-Edition, media library settings, webhook support, and the ability to limit roles for administration users. You can create different roles and add different users. Strapi is pretty configurable, and you can change the port and host in the server.js file. Now, let's take a look at how to make a request to Strapi and configure permissions for endpoints.

When making a request to the books endpoint, we initially get a 403 forbidden response, which is expected. By default, Strapi has two roles: authenticated and public. We can define actions for specific applications, such as the books collection type, to enable different types of requests like count, delete, find one, update, find, and create. After configuring the permissions, we can successfully query the books endpoint and retrieve the data.

To configure the settings for roles, we can navigate to the user and permissions plugin, click on roles, and define the actions allowed on the specific endpoint. Strapi provides an administration panel where you can manage roles and permissions. It's important to note that roles should be managed under the user and permissions plugin, not in the general roles section. Additionally, the Strapi directory contains files like package.json and server.js, where you can customize settings such as the port and host.

And, and what we should get, oops, ooh, why? Very weird, anyway, we'll just do it old fashioned way. So let me zoom in a bit here, when we make the request to local host 1337 slash books, we'll get a four, three forbidden, which is very normal, this is exactly what we want to do. Out of the box, we don't necessarily want people interacting with endpoints that we haven't properly configured or that haven't been given the right permissions, or like, things haven't been set up in the right way. And I wanted to do this so I can show everyone how we actually do something like that. So, ah, okay. There's another workaround, which I can show you for getting or changing the port. So, Strapi is pretty configurable, which is one thing I mentioned. After doing this, we'll peek around the Strapi, what do you call it, the Strapi directory, and look at how like a Strapi app looks like.

Okay, so, what I was saying, yep, our endpoint, book's endpoint, is forbidden, which is great because we haven't configured permissions for how we want to interact with that endpoint, or how we want people to interact with that endpoint. By default, we have two roles, authenticated and public, and these sort of dictate how people interact with our endpoints.

So, this is, the public role, of course, is for an authenticated user. And when we come here and scroll to application, so now we can define actions for specific applications. So for our books collection type, thanks Felipe for the fix. So for our books collection type, we can just like play around with these and see what we can access. So when we just click here, we don't tick the box, but just click the section that it's on. We get something really nice here, which says the type of requests we can make on which endpoint. So count means we go to books slash count. Delete means make a delete on books slash ID and find one, we didn't mean to tick it, and find one is books slash the ID of the book. Update is a put. Find is a get. Create is a post. So we can make all these operations or we can enable these operations by ticking certain things. And remember, when we came to the books endpoint, it said forbidden. So we'll take this so we can actually query the books endpoint. And when we do that, we finally get our books, which is pretty cool. So we have quite a number of pages and then we have some additional data for when it was published, created, updated. We have our cover image with details. There's the name, the URL for the image. And yeah, that's pretty cool. So now we're able to access our data.

You should have a public role. We can just click there. Let's do that to start and navigate to settings. In settings, under user and permissions plugin, you should click roles. And by default, these are the two roles that we have. Everyone should have them authenticated and public. And then you can click public. And then now you can start to set the settings like we just did to give yourself or to give your define actions allowed on that specific end point. Let me know Bruce. Oh, yeah, I'm guessing that's Alex. So there they can be a bit confusing. There's administration panel here, where there's roles, which are the three roles you see. What you're supposed to do is go to roles under user and permissions plugin, and then you see authenticated and public. So not here, but here. No worries. No worries, it's all good. That's pretty much how we do things. Let me open up like VS code and get things. What did we name this blog? Okay, so, let's just zoom in. This is your strappy folder. And these are a couple of things that you should see. Like I said, it's Node.js. You've, of course, got a package.json. And in config you should have server.js, and then you can sort of set, if you wanna change what port, if you have problems with things, so you have like your admin secret here, and then you have your port. You can change this port to anything else. You can change the host to something else too. You have like a database.js, which like I mentioned, because we're using, and my SQL will just have like a temp TB, which is exactly why you probably shouldn't use that in production. We have a couple of things. If you wanna set up cron jobs, we have a nice section where you can run a couple or set a couple of cron jobs, a bootstrap function, which can be really useful for making certain operations occur whenever your Strapi app starts. This is just like the admin build. And then we have the API section, which is really, really interesting because now we're getting into like the architecture of how the Strapi backend works. A lot of people love to customize these things and add custom functionality, either checks before things get into the database, hashing passwords, appending things, all that can be done either through services or the controllers. But that's more intermediate to advanced Strapi functionality. But yeah, that's pretty much what a Strapi repo looks like and just some like boilerplate stuff. Yeah, cool.

So what I'll do now is change directors really quick to React advanced. So we can play around with Next.js. I don't see any questions. Is there something, or maybe let's do this, actually. Let's install GraphQL just so we can show you how GraphQL works with Strapi because that's something a lot of people are really interested in. So we're back in the command in the terminal and we're in the blog folder, which is where our Strapi app is. And we'll run npm, npm run install, npm run Strapi install. GraphQL. So we install GraphQL and then we can use it. Yeah, we could add the Slido one also if you'd love to have it. I'll install it right after GraphQL. Yeah, that's something a lot of people are really like, let me see if I can pull this up. Yeah, we had a webinar with the folks at Postman and we were playing around with the documentation plugin.

Let me see if I can send you a link. This is like a recap of the webinar that we had. I'll send that into the Discord also. I think it was a really cool thing. Shouldn't really set up a lot of interesting things in there. So I'm just waiting for the admin to rebuild. Let me know if this is too small and I need to zoom in, by the way, more than happy to do that.

Awesome, yeah, should be done pretty soon. Apologize, I have way too many tabs open. So generally things are a bit slow. Hey, while that's installing, let's get like our next app started. Let me zoom in a bit there, see if it's similar. Okay, it's installed actually. So now let's install the documentation and we'll do the same thing, it's NPM run, extract the install, documentation. Yes, it will be recorded and will be available later. I think they're recording right now. So while that's installing, let's do NPX create do like the usual next app my project, admit let's pull this and client sounds like my bad, NPX. oh my bad, NPX.

Okay. Now the admin is rebuilding and then we can play around with the graph QL and documentation plugins. By the way, if this is all looking really cool, thanks, Bruce. If you think this is amazing, wait till you see the next version. So right now, to be honest, you probably shouldn't check it out, but I will show it to you. We have my Acha Lica, much smoother version of Strapi coming out really, really soon. So the version you see right now is Strapi V3.6.8. And we have a, oops, we have a V4 coming out soon. And this has, there's, like, so many things that are really cool about the V4. Maybe I should run it, if we have time at the end. So we have, like, a much more streamlined and developer-friendly plugin API. We've improved our, sure, sure, let me send the command. No problem. Let's just go back. So I ran, NPX create next app. Thank you, Alex. And, yeah, that's what I ran. And our next app is done. And let me just finish up this thing. So better error handling, new database layer, new REST and GraphQL APIs is like a couple of things have been hyped up and then basically the beta is out. But yeah, back to Strapi and next.

So yep, we have our documentation plugin installed. We have our GraphQL plugin installed. We're in the blog directory. All we have to do now is run NPM. NPM run develop, to start our Strapi server. I'll just send that in the chat in case anyone wants to run it. So our Strapi server is back up and running. And first things first, yeah, and it really does. When you go to plugins, let's refresh, you go to plugins, now you see that the documentation plugin is installed and the GraphQL plugin is installed. So when we go to documentation, we have all this and what we can do now is open up our documentation. And now we have like this Swagger UI for the strappy collection types that we just created. So we have books and now we can test out and try out different things, which makes it much, much easier to play around with these things and make requests and build out applications. So that is really useful, really, really useful. And you have the same thing for the single type. We have an email provider also. So that's the documentation plugin. If there's anything specific that you'd have wanted, I think we can try and squeeze some time in at the end. And before I go into GraphQL, I think when I was looking at roles and permissions, we talked a lot about the public role, but we didn't necessarily talk a lot about the authenticated role. So with the authenticated role, what this does is it sort of adds another layer of security to your end point. And whenever you enable certain actions for different end points on the authenticated role, the only way to access that is by sending a JWT token with your requests, by putting that in the header, so it's like bearer, and then you have the JWT token. And once that is confirmed as a valid JWT token with the Stripey server, and then you have access to that data. So you can sort of gate your data with your authenticated role. And the way to get your JWT token is by passing a user. So we have users here that we can create. You'd be asked to put in like a password and a username or an email. And then we send like a request to a certain endpoint. It's your Stripey URL slash auth slash local. And then we get back a JWT token should our password and username be correct. And then because someone mentioned authentication, we have an email plugin here. Sorry rather provider plugins. So what this means is you can set up all these providers to register users in your Stripey app.

So you can use Auth0, Cognito, Discord, no more email, Facebook, GitHub, Google, blah, blah, blah. So basically in your client app, you set these providers up and then people just click sign up with Google, sign up with Facebook. And then those get converted into users in Stripey. Those users can then make authenticated requests to your Stripey endpoint. That's if you want to keep your content gated. But that's practically it. I just thought that's worth mentioning.

Okay. So we've looked at the documentation plugin. Let's look at the GraphQL plugin real quick. I don't want to like rush through everything else because there's still a bit to get through. And so, yep, this is the page. So let me just take that out. So this is your GraphQL playground, which is like an IDE, integrated development environment that helps us like test out queries. And one thing that I like about it is, it sort of has this auto-complete feature. But before we actually do anything, we can have a look at our GraphQL schema. And you can also have a look at this locally in VS code. Where is that? Yeah, we can have a look at that here also, but we won't. And we also have nice docs created for making queries and seeing what's possible. Different operations are possible. So if we want to do books, and we can see what fields are available inside books and what type of things we can get. So if you aren't familiar with GraphQL, you have two types of, or three, but for now we'll focus on two types of operations, which are queries and nutitions. So queries are... With queries what we can do is, it's like the name suggests, so we're querying data, we're getting data from a source and then we're getting that data back. An example of this here is... And you see that auto-complete that I mentioned. It's very intuitive. So it's we're typing a query, what do we want the query? What are we trying to query? We're trying to query books. What in books are we trying to query? We want to sort of get the ID of books. We want to get the title. We want to get the... What else? Page number. Number of pages, sorry. And we want to get the cover. And in cover, we want to get the URL. So this is sort of what queries do. And then we get everything back, which is nice. And it's pretty much the same with mutations. Mutations on the other hand, are... As the name suggests, again, you're mutating data. Which means you're either changing it in one way or another. I'll get to your question soon, Felipe. I said your name right, by the way. So with mutations, what we're doing, is we're changing data in some way or form. And I think this is best shown by the docs here, if you go to... Where is that? Mutations. So we have, we can either create a book, that's a mutation. So we're creating a new book entry. We're updating a book entry, deleting a book entry, and these are all mutations that we have access to. So ideally we would put in some inputs and then yeah, we could make a mutation. Let me see. We're playing a lot around, be playing around a lot with the E4 and the structures a bit different. So let's see, create book. See, is it input, create book input data title, what title could it be? I've got a book to read. I think that's an interesting book. Then the div. And what else? Number of pages is, hopes are short books are maybe like 75. And then at the end of this, we want to return book. This should work? Oh my bad. And this actually should, this should not work because we haven't set permissions up to do this, but it's a good opportunity to go back and look at that. So there we go, forbidden. And now we can go back into our Strapi app, again, to settings and then roles and providers, public. And now if we go to create, we should be able to make this work. So there we go, the dip. So that's like mutations. And now if we go back and query, query this data, we query books and let's just get names, title sorry, we should see three books. Right, client, search one, the dip all yeah, all done using GraphQL. Okay, so Philippe is asking if there's a way to get absolute image URLs and just for context, let me show you what it means. So when you query the URL of a book right now, what's happening is you're only getting sort of this like relative URL, depending on where this is deployed. You have to sort of append this URL to that domain name, and yes, you can get absolute URLs, but to do that, you'd have to use a different provider.

It's because Sharpie's self hosted. We really cannot assume in advance where your thing is deployed. And sort of to do it that we have a bunch of upload providers for images and media in the media library. One popular one is Cloudinary. And when that happens and you use Cloudinary as your uplink provider, whenever you upload data to the media library, that is stored in a service like Cloudinary. There's one for Microsoft Azure, there's one for AWS, there's one AWS S3. So what happens is whenever we enter data or media in the media library, it's stored in that third party. And whenever we make requests, we get absolute URLs, rather than this type of URL. I hope that answers your question.

Okay, so that's a lot of strapping. Let's get into building out. Yeah, okay, cool. Yeah, let's get into, yeah, and you can see all these request in the terminal that we're making.

Sorry, another question, absurd mutations. What are absurd mutations? Sorry. I don't think I'm familiar with this. What do you mean? Yeah, while we're waiting for that, let's do this, change. Oh no, we're trying this in the wrong directory. I thought we changed directories. We did not. So we have to run that again, my bad, sorry. So we run, yeah, so this is a command we're running now just to set up a next JS project. Again, sorry.

Oh, okay, I see what you mean. I will point you towards the GraphQL RFC, which sort of gives you a good idea of what's coming up in Strapi V4. But we have, yeah, it's probably in it. I will have a look myself and see. But if it's not, I think that sounds like an amazing idea and I will probably ask the engineers to work on that. Or at least to add it to, roadmap. I'm actually actively looking at it right now. Yeah, as far as I can see from the RFC it is not, but you know that sounds like a brilliant thing to have, if it is standard, and I will try and get that for you Filipe.

Okay, so back to, yeah, now here we go. So client and npm run dev. Okay, so now we have things running on localhost. So, localhost 3000, open that. And we have like the usual next project and keep building our page. Gotta wait a bit. Okay, there we go. So welcome to Next.js. We have the usual stuff that we see. And let me open this up actually in Vs products because it will be very useful. So go through the repo, I mean the directory. I keep saying repo, sorry. So I don't know, is anyone unfamiliar with Next.js? So we have like a Next folder here where we have a couple of things that make Next.js tick in the background, patch server static, build manifest, node modules of course for all our dependencies. And just because this is sort of like big enough, I will have this section here. Sorry, let me just check the slide, okay. Yeah, we have this page section here which I find really, really interesting. So the page that we were just seeing here, welcome to Next get started by editing pages in Next.js. So we'll do just that. Let's go in Index.js and start to edit stuff. So we have the head section which says like the page title and everything. Then we have the main section which says welcome to Next.js. And then get started by editing. Then we have that, which is like the page name. We have these next cards and let's actually edit something. So just above that, let's put like a P tag. What do we save? I think from React advanced. Advanced. Controller app of course as well. Save that and just put update. What? What, did we start it again? We did not start the server again, my bad. Let's just do npm run dev. Start our server again. Okay, now, wait just a little bit, oh it comes up, compiled successfully. And now, here typing from React Advance. So yeah, I think we can like duplicate this, duplicate that, name it something else. What do we name it? test.js and we go to... right? So let's see now inside test.js we can sort of say, typing from React advanced in the file we just made. And there we have it. So what is all the jazz about next.js? I don't know if people here have had experience with a tool like React or in general, just building something for the web. Next.js sort of makes things easier. Let's say that it of course has a lot of really interesting features and advanced feature sets besides just making things much easier, besides making routing and not being as, or, I mean, there's still a lot of room for playing around with different state management or different types of building, either multi-page, single-page, static service side rendered. It gives you a lot of flexibility in what you can do, but I think the best thing that it does is it lowers the barrier for entry for someone wanting to get up and running with building websites in React. And then that coupled with the platform that Vercel is, I think it makes it much easier to go from development where you're on your local machine to production where you have this thing being used by people who actually need to use it, whatever app you're building. And that's the really cool thing about Next.js. The really cool thing about Next.js. So this is sort of why I chose to build this thing out with Next.js. So now we, now what we want to do is build out a block. I don't know if you have any Next.js specific questions.

Besides that we have like a public folder, a bunch of config files, package.json, styles, page and yeah, we have like an app, underscore app, which is sort of like the base of our web app and we can add a bunch of config and change how our app works.

So now that we sort of want to build out our block, I want to go back to the slides physically, but just mentally want to take you back to the slides and how we were thinking about content first and where sort of think about how you would approach building something. And even though this is just like building a blog, I get the goal of this is to sort of give you the blueprint and like a firm foundation of how you would approach something from a content perspective whenever you want to use like a headless CMS, be it Strapy or anything else, I think you need to start from the content and what that looks like. Design wise, I already have like an image of what the blog would look like, so ideally the next step for us is to sort of structure our content the way we want to be presented to our front end. And like I mentioned in my slides that's starts out in the backend.

So we're going to do an exercise of content modeling, which will be fun. So, let's go for it. So we're going to build a blog and this blog will have writers, this blog will have articles of course, and then each article will have a... Each article will have a category and then you have a bunch of different categories also that sort of... Yeah, it's described where your article lies. So we'll start by doing that in Strapi. We'll go back to Strapi and start building out this content model. And then once that's ready, we'll come back to the Next.js app and then start to add the code that actually powers our blog.

I think we're about halfway. Usually I think people might want a break. If you're good to go, because I think we have... We're like, literally at the halfway point. If you would not like a break, please drop a message and I will carry on. If you would love a break, let me know, so we can... Yeah, sure. Let's do five minutes. I think it's a good compromise. Let's do a five minute break. We will head back here. I think it's pretty much a natural stopping point. So five minutes and then we're back. Cool. See you all in five minutes. Right now for me, it's 5.18. Let's say we're back at 5.23.

Hi, hi, hi. Hello, hi, hi, hi, so we're back. I'm backstanding. While we wait, I'm going to put up a few polls. So you should see something in the polls section. I'd love to hear from you about how you're using or what you're using for your back end. Right. So lots of people using headless CMSs. And custom databases. Okay? So something that I haven't put in the poll that you use, please let me know. Nice, nice, Bruce. Glad to hear that. A very interesting polls that are going to come up after this also. So, I think we're ready to begin when 35 out of 41 people have answered the poll, then I'll know most of us are back. We're at 26 people, get out there and everyone. Just... Open it. Open it right up soon. 28. We need to get to 35 so we can start. 29 people have 28 people have answered the pause everyone back. Should I just assume that people who haven't answered haven't used it? Okay, great. Give me a minute. Then we'll get started with building our content model and then building our blog. I have something that I want to share. So, in the poll, it's interesting. Very, very interesting to see. Share these results. So much you can see the results. Okay. I'll stop sharing and in about an hour I will share another poll. So, I'm going to go ahead and restart everything. So, we'll start up our server again. Yarn develop, or npm run develop. This is our Strati server. Let me just look at the chat. It looks like this is an activity. Awesome. Okay. Just waiting for that to start. Okay, we're up and running. And where is Strati, where is the browser? Here we go. So, now we can get started building out our content model. Here we go, no that's not it. Here we go. So, we before we went off for the break, we found out or we at least defined that we want our blog to have categories, we want our blog to have articles, we want our blog to have writers. So we'll start off by doing exactly that. We'll start out with a categories, collection type. So we'll go to our content types builder, click a new collection type. And then we'll name this category. That's good. So what we want every category to have a name, short name, and you can follow as I'm doing this also. And if you don't, I'll give you a command at the end that will sort of set everything up for you, like a template.

Then we'll add another field, and then we'll have a slug. And we want our slug to be a UID. So we'll say slug, and then we... The thing about UIDs is you can attach them to certain fields. So what happens is this will be generated automatically based off whatever the name is. And then that's pretty cool. So we'll finish. And so right now we have name and slug, and then we'll save that. And we'll wait until our servitory starts. Our activity is done. And now what we want to do is we want to have a... What do we want to have? We want to have a writer, so writers. So content-types.buildup, create a new collection type. And then we'll go ahead and name this writer. Okay, what do we want writers to have? We want writers to have... Writers have a name, of course. I want writers to have a picture. A picture can mean... I think that'd be a picture, sure, media, a picture. And single media of course, so add another field and this would be email. We can just have it like this. We can use a text field and let's name this email. Finish. So we have two pictures, delete that one. And then save. I don't think that's possible because if it's restarting, then it's not up. So no one can access the content. And then, last but not least, we will have article. And now let's think about what goes conceptually. What goes conceptually? So articles, of course, have a title. Add another field. They have a description. It's a bit long. They have, we use rich text here just so that we have like the article content. And we'll add in article slug also. And we'll attach this to the title. Add an image, just in case we want like a cover, and a single media also. And now we get to sort of see how relations work. So we want an article to be related to a writer. So you have a writer there, and then what type of relation do we want the article to have with the writer? So every article has one writer. So basically a writer has many articles, right? We can sort of toggle through this, article has and belongs to one writer. That is true, but a writer has many articles, and this is the most ideal. But no, we do not want article to belong to an as many writers. So we'll just, we'll go ahead with this. And then we'll add another relation for category. So we'll go to category and what we'll have here. Let's see. Each article has one category. Each article has many articles. Each article has many, nope. It's this one. Category has many articles. So we have one category, and then many articles are sort of attributed to that category. That makes sense. We actually don't want to add anything else yet. So we have seven fields, title, description, content, slide, image, writer, category. That makes sense. So we'll save this and we'll restart. It's going to take a while. Just in case you are left behind, I'll send something that can get you up and running. You can use a template. We have like pre-configured, Stripey apps and what I'm doing right now is building our blog template out. I'll send that in the chat. If you want to skip this and dive right into the meat. So just put that command into your terminal and then you have all of this already configured with entries already, which will help us get to the next stage much faster. So that'll be helpful. Yeah, welcome, by the way. You can get recordings after the session or not immediately after, but they will be available after the session. Okay. So we sort of built out what we want with the collection types.

And then we'll look at the others. We have category, which you can see has a relation with Article. And then we can start to add a content here. And let's try and add an Article and you see what I'm, but before we do that, let's add a couple of categories. So, I don't know. Tech is usually a category. And, what else is category? News is usually a category. And let's go back real quick to writers. Let's add a writer. Who would like to volunteer to be a writer? I'll start with like, myself. Get this image because, use Daniel. We have a couple of articles. We don't have any articles yet. We'll save that. And then we will, here we have one and we can go to the article now. Now we can sort of see how displays are. This is the editing experience. We've edited Daniel. Our slug has been auto-generated. And is doing a workshop. The descriptions is a workshop on building them as driven products in 2021. Content. This is like blah, blah, blah, blah, blah. This is so we can have something. And now we'll sort of see that we can assign a writer and we can assign a category to this article. Which is exactly what we want. And we'll save that. Now there's issue because one of the categories, oh no, sorry, one of the writers that we edited was not published. So we've published that. And now we go to articles. And now we can publish that. So everything's good. Everything's good. And then when we query, let's go to articles. Let's just use GraphQL real quick. Okay. So query Oh, and now we want title and ID. You can also get like writer and name, category. name, stuff like that. And then we get that back. Well, we have in a given also the permission to do that. So as we did last time we will give permissions for find.one find.one Yeah, and write to find.one. Yeah. Perfect. So there we go Danielle's in workshop. Offer Daniel attributes. Barely any news, but there we go. So where were we?

And now we can build out the single types that will be essential for our block. This gives us an opportunity to play around with the components collection types. So we'll go into our collection types folder again. And now we will sort of see how components work. So a new component, let's call this SEO. Select a category. We'll name this Shared. And because we're going to be able to share that SEO, like upwards arrow. And now we can build this component. We want a meta title. That's short. I'm gonna say SEO, we want like a meta description. Meta description. And we should do much longer. And then we'll add like a share image. Image, yep. Share image. And single media. We'll finish. I will save that. So now we have an SEO component that we've created. Go ahead and now create a global... A global single type. Which I guess will explain really well what the usefulness of single types is. It's like global details for, a webpage or a blog. So we'll start out with an image. We want to define our favicon in RCMS. And that'll be single media. We want to define our site name. Strip text. And we want to define our... We want to add like an SEO attribute actually. So what we'll do is we click component. We can name this, we can name this like default SEO. SEO. And now we can select. So we can use an existing component. Select component. We don't want this to be repeatable. So single component. Like I said, name this default. Select our component, undershare we have the SEO component. That's pretty much it. And now we have this show up. We can add this to literally anything else. So we can go to books and add the component. And then this is much easier for stuff that you want to reuse in multiple sections. So if we ever want to have like SEO for an article if we ever want to have like the meta title when we share on social media we could literally just come here and create a component, use existing component, article SEO, and then select the component single, and then finish. And then we have an article SEO portion which we could connect to like the head portion of our next app basically. Yeah, we will not save that. Yes, confirm on cancel. So that's pretty much it on like creating this stuff. Now, like I mentioned, I will share a link. Let me actually share a link because it would make the next portion much, much, much easier as we build out the blog. So this is a bitly. Let me know you have access. I'll just put that in the Discord. There we go. And I will send it to chat. Yep. This'll make the next section much, much easier. So like I mentioned, we have a lot of content that we created. That's just building out and you know, from thinking about it, how we wanted it, we knew we wanted a category feature, we knew we wanted writer feature, and we wanted those things to be related. So we made them related with relations. We knew that we wanted writers, categories, articles, and then we also created a single page, a single type rather, that can hold a lot of the global data for our site. So what I'll do now is in choose and run this command and you should do this because if it will give us the proper foundation for the next part, and I'll just go to the Strapi app, strapi-blog-backend, we've got the other one in design, so let's just put this API, actually. Yep, so it will build up a pre-configured blog. So it'll do everything I just did and make sure you select the quick start which is recommended. Yeah, it will build out everything I just did, that thing, just so that the next section is much easier and there's like no mistakes in between that could probably make finishing up the blog site much harder. So you should definitely go ahead and run that command.

So you should definitely go ahead and run that command. I'll send it in the chat again. But if you clicked on that link you should see everything that I was just saying and keep track of how things supposed to look, how your content models was supposed to be, the different types of components is supposed to create and how things work. So, yeah.

But now we're gonna get into like the next portion. Thank you Bruce. You know, we'll just wait for this finish. Alright. Does anyone have any questions at this point? I think there's a couple people who joined. I'll just take you through what we've gone through and I would advise you to have a look at the link I just sent. Yes, yes. I will show a static web app which is exactly what we'll be building soon. See, that's very weird. Let me know if anyone else is getting that issue. Okay. Weird. Okay. Let's just go back. Where are we again? Getting advanced. Okay, there we go. And then we name this API. We are going to build a static web app for this. So what I'm doing right now is installing the template so that it gives us like a great base. I would advise everyone else to install the template also just so that there's no mistakes as we go into the next portion of the workshop. It should be done in a few minutes. And then we can get started. Right. So let me just talk about what we'd want this to look like. First of all, it would probably have components. How do we want these things to look like? I think we'd structure this. So we have a main page where we go to, and then that main page directs us to a specific blog. So when we click on one of the articles that we see, that takes us to this section where we see a bunch of different articles. I mean, the actual content of the article. My bad.

So of course, what we'd start with is, and let me just start this up again. Okay. It looks like it's running. So we have our next app here. I'll just refresh that. This is exactly how we left it from last time. And we'll go back to a terminal and install a couple of things. And if you have the webpage that I sent you, you should have, it should look something like this. And if you go to setting up a blog under install packages, you can copy this and install everything. So you can either follow along or go along with what you see in that file that I just Next up, install markdown, react markdown and ReactMoment. ReactMoment helps us work with time so that we can say when something was published, when an article was published, react markdown, helps us put markdown content and display that as HTML, you know, pages, because we're getting, we could deploy this app on Vercel. Deploy this app on Netlify. But yeah, time's a bit of a time constraint, so I hope we can get to that point. I'll just look at that, admin is building. Okay, so we've installed the necessary packages and then the next thing we want to do in our next app and just so you know I have VS Code open here. We have our next app. This is our next app code. And this is where we will be working from here quite a lot. So we'll be switching between localhost, and we should go back to 300. 3,000. Right. Excuse me. The terminal. Okay, so this is our localhost. Yeah. So we just installed everything, and then we'll start our server again. So NPM. NPM undeveloped. And yeah. Sorry. You're looking a strappy. And, okay. So for the quick switches. Back to the strappy section. Now that our template is done. You should be redirected to a local student 37 slash admin.

And then, your stripy app should start and once you open that strappy app you should see your content models built, and you should see entries. So, we'll go into here. Stropy admin, create something really quick. And then, we go here. So this is exactly what I meant. Go to our content types builder and we look at our collection types. You should see this built out. You should see this built out. The component also, SEO. You should see that built out. And then if you actually go here, you have content that you can actually query and play around with. Great. And all this should be available. Should you have run that command that I sent? Okay. Now that that's running, we can totally focus on next to S again. Right. So what we just did. Thanks Bruce for sharing. In the zoom chat. 10 PM. Do you still react Mark down and react moment. Now what we want to do next is us to traffic TV as good. And now switch over to PS code. So what we want to do now is. In our route. Create a new folder. And inside assets need to create another folder for CSS. So what we're doing is. Then inside CSS, we need to create a new file for style. Style CSS. And inside that. We need to paste the code that you see in the snippets. Everything is. In the page that I shared with you. And what this is, is just. Different. CSS classes and different CSS properties for. Okay. So once you've done that, now we're ready to sort of start building out things. But before we do that, we need to set up how our. Next app. Calls our stripey app. So remember, we either have graph kill, or rest. Apis that we can use to talk to our strappy app. So what we want to do is create a new folder again. Code lip. And inside lip. Create a file. Called api.JS. And really quickly, because we have 30 minutes left. We will put the code. So what this does is we initialize a function called get strappy URL. Which either gets an environment variable, code next public strappy API URL. Or localhost 1337. We can go ahead and create, save that, and we'll come back. And we'll create a dot end file. And just... And dot end file. We will initialize that value as our URL, which is just perfect. And then back to this. Then we have another function, which is fetch API. And what that does is we define request URL and then get a response and then we parse that response and then send that data back. So because fetch the fetch API function, it gets this URL and makes a request and then parses that request and then returns back the response data. And this is like I mentioned, how our next app interacts with the Strapi API. And this is because there's a really important question that was asked around how we manage media assets. So you can either use like specific domains, it can check what your Strapi URL is here, or maybe you have an absolute URL if you're using a third party upload provider like Cloudinary or AWS. We use that to manage our media in a very systematic way. And so because of that, in the lib folder, we'll create another file called media.js. In media.js, the first thing we'll do is import the GetStrapURL method from the API file, and GetStrapURL just gets either the n variable or Locos 3037 which we define, either here or in our N. So the first thing it does is it gets that, and then we'll define another function, GetStrapiMedia.

And what this does is it looks at an image URL, and it asks, okay, does this start with a forward slash? If it does, that means it's one of those URLs like we saw in Strapi. Let's just go to... Let's get articles. Yep, so if you look at that, this URL starts with a forward slash, right? And what that code does is it says, okay, if it starts with a forward slash, that means it's not an absolute URL. And what we need to do is append this Strapi URL to the media.URL that we're getting. Or we can just serve the media URL as is. So that's what happens with this code. And now post this, what we need to do is make an update to our pages. Remember, app dot underscore, what is this? Sorry if I'm rushing through, I didn't do a terrible job managing time. So I'm really hoping that we get to everything that we need to get to, okay. And then this section is really fun too. First thing to do is get rid of all of that and then import a couple of things. So we're putting app from Next.js app, which we just got rid of, we're putting head which helps us define items on the page head. We're importing our CSS, create context, the fetch method that we just defined and the get strapping media method. And then now, what we're gonna do next is get a couple other things. So we have a global context, which is just setting up what our page looks like globally in terms of SEO and how it's managed. So get strappy media is what's called. And then we call global, which if you recall, we go back to our content manager. We have a collection type and we have our favicons stored here. So we're setting up favicon by making a request from strappy and then defining it in our app.JS file. And we're doing the same thing by providing all this global data to Next.js so that we have the page name, the site name and meta description for our blog, as well as the shared image for wherever we share it. So I just really hear optimizing for SEO, if you can call it that. Or if you'd like to call it that. And we're doing pretty much the same thing, getting our initial props by... and this is just our request. Again, we're using Fetch API, which is the function that we just defined and calling the global endpoint and then passing that data into our props and getting global, which we then pass on to Next.js so that it knows that this is what my web page looks like. This is the meta data that makes up my web page and the head tag. So that's pretty much why we're updating this page. It's the part that isn't as fun, but usually has the most impact. Great. And then we need to sort of keep doing that, the not so fun parts. So next thing we need to do is create a underscore document.js file. And what this does is it helps us modify the existing document page. I already introduced you the concept of editing the head and body portions of, like your Next.js web page. So we're gonna pretty much go in the same line and do that with our document page. And this is sort of like, if you're a traditional developer who's worked with like vanilla JavaScript and HTML. This is sort of like injecting scripts into like our HTML file at the top for things like CDNs or different scripts to run different libraries. So just inside our pages folder, we'll do the same thing. We will create a new file and we'll call this underscore document.js. And come on paste, it's a lot. And I'm hoping you all have the, yeah, and then, I keep getting this error. So what I will do is just, it's a document, sorry. Wait just give me a minute. Let's see what the, it's just referred to the actual next documentation. And I should probably fix that. It's document. Thank you so much for the correction. So it is pages slash document.js, confirmed. Okay, there we go. So document.js, and I have no idea why we're getting that error because this is the document.js file. So I'll just ignore that and you probably should too. So in quick fix, just say disable on this line if you're using ESLint, if you like things looking pretty. And like I mentioned, what that does is it helps us extend the existing NeXT document by adding different links into the head section of our HTML file for our NeXT app, and what this does is it adds the Google Fonts API for the font that we'll be using on our front end. This is for the UI kit, which is the UI library that we'll be using for building out this blog, and the rest is icons and other UI kit, the CDN stuff, which we are just injecting into the document, and that's why we're creating the underscore document.js file. Cool. Now, we had a, what did we call it? We had a, we had an SEO component. We had two, let's go back. We had two single types here. We had this homepage which sort of stored our SEO data as well as some hero text, right? And then we had a global single type. We've already seen how our global data has been used. We're injecting that into the next HTML file so that that's aware of this content, aware of this metadata. But we haven't yet seen how we use the homepage data which is what we're gonna do next. Cool, so back to VS Code. What we're gonna do next is create a components folder. Just clean this up. And then create a new folder called, components, components, no, no, just folder, all right. So inside this components, we should create an SEO.js, a new file SEO.js. Okay, then we have this SEO code. We'll do it slowly. So the first thing we do is we import a couple of things, head, because that helps us modify the head section of our html file for next.

Use context, global context, and strapping media which helps us manage media. And then we start to define a couple of things. It's a really long file, but very useful too. So let's just paste that there. And let's like just go through what we're doing here. Right. So we're defining a couple of things. And before we go up there, I think it makes more sense to just to start here. So we're getting a couple of things, our meta title, which we're getting and setting, our shared image, which we have from Strapi. And then we're setting this up and using this as constants. And then we're passing that into the actual head. So what we're doing here is we're setting our title to a meta title and then we're setting our page meta title as well. This is for Twitter. If you want to have those nice Twitter cards and this is for platforms like Facebook and LinkedIn. And you're basically doing the same thing for your description and for different platforms. And that's pretty much the reason why people fill that in. I think for a lot of people, these are the things that are really important. And if you share something, you want it to have that description, that image, because it's more appealing, more visual. And that's what we're doing with this SEO component. And it's just really cool to see how it sort of trickles down from the CMS to your web app. So yeah, that's the SEO component that we're doing. And now we can actually get into like the others stuff. So next we need to create a nav.js file. I realized that I didn't add these are going to build them out, but realize that we don't necessarily have that much time. Okay, so. A minute. And I shall provide you with these. So I should probably add this to a GitHub repo because that'll be much easier to share. One minute, sorry about that. Right. So, most great web apps have a navigation section, right? And that's what we'll do now. So inside our components again, create a new file, code nav.js. And we'll paste in the code that's supposed to go there. And I'll just make this a bit smaller because it's filling up everything. So we import a couple of things, react and react link, sorry, next link, which is next way of helping us navigate through web pages. And then this is the portion that we return. So our navbar, this is what we're building, we're basically building our navbar here. We have a section that says A blog, and then we're fed in data that is the categories that we get from our CMS. And then we map those out and create sort of a left, right, sorry, a right menu of all the categories that we have. So we can just click on those items and then navigate to the different categories. Oh, yes. That is me, I have to actually put them after I, there we go. You should see nav now. I'm adding those in real time. Let me actually just add all of them so we can go ahead much sooner. Think that'll make it much easier. The next one is this. Yeah, just give me five minutes. Look at that. I don't need to do the numbers. Okay. Almost there. Okay. Okay. Okay, now we can continue. So we've created our nav bar and now you should probably see everything. We've created our nav bar and now we can actually utilize that nav bar by creating sort of this layout that we want our webpage tab. So, we'll get a new file and create something called layout.js. And what layout.js does is, let's put that there so everyone can see it. We import our nav bar, which we just created, and then we create this new layout component. And then we feed our nav bar section and then pass in categories, because remember our nav bar section has or at least utilizes categories because it needs to sort of map those out on the nav bar. So we should probably check our web app, see how it's doing. See if we've got any errors. Yep, nothing is showing up yet, but the UI has changed because we've changed styling. Why is nothing showing up? Because that webpage is fed from our index.typing. js file, and we haven't changed anything there. So until we're done with components, we pretty much won't see any changes in our index.js file. On the plus side, nothing's broken. So that's great. Okay, so the next component that we need to create is, oops, my bad.

The next component we need to create is an image component. We're gonna use next image to sort of make sure we're optimizing all the images that we're using. And inside components again, new file, image.js. Right, and then here again, you notice whenever we have to deal with images, cause we're not really sure if it's an absolute URL or it isn't, we have to import getStrappyMedia and then we import next image, which optimizes images. And then what we're doing is we're practically just creating a component around next image and then setting up a bunch of these properties with width, height, source, and loader, and then sending that into wherever we're gonna use that. And where are we gonna use this image? We're gonna create a new component called card.js. And this is sort of be a card that has the image and some text. So we'll copy that. And like I said, we're using the image component that we just created. So this is the link, first of all, because whenever you click it, you should be redirected to article slash the article slug. And then this is what we click that takes us to the next page. And then we have the ref there, these classes are just for styling. And then here's where we passed in the image details, and then those get processed by the image component. And then here we pass article category, organized, and right below that, the article title. And once we start to build out our index.js file, all this will start to make way more sense.

Okay, and last but not least, our article. What do we actually see when we click something? Or how are we arranging things? So another file, article.js, and we'll save that. So here, we're defining a couple of properties for the way our UI will look. So our finished UI will have a couple articles on the right, on the left, sorry, a couple articles on the right. And this is just defining that object and slicing up articles so that we can display them and order them with the way that we want them to show up. And then here, we just map those out into the UI and render them. So we have the articles that are on the left, and then we have the articles that are on the right. That's pretty much it. And this also to make way more sense now that we're actually going to edit our index.js file.

So now, it's the moment you've been waiting for, index.js, you have the code there also that we need to get. And so, you can literally just take all of this out and replace it. But before we even look at anything, we need to look at what we're doing. So we're importing articles. Remember I told you the UI will sort of be skewed because we have some stuff on the left, some stuff on the right. And just that we know, we can add like an extra H1 tag. Let's say, hey, this is the VAT file. Okay. So here we get the articles categories homepage. We put the categories in the layout so they're on the nav bar as we want. We have the SEO component and we're passing in data so that like web crawlers and different social media sites are aware of the meta data in our page. And then we have this title section, which we get from the homepage also. And then we have this thing that we just added. And then we pass in articles so that it's displayed in the article component laid out on the left and the right. And below that, we have our get static props function. And what that does is we make a couple of requests at both times so that these pages are populated and then we get returned something. And then that what we get returned is passed into props. And then that's used in the page component to power the different components that we just imported. So we'll save this. And then now let's look at what things look like in the front end. So component articles cannot resolve, it looks like we misnamed something, we named it article, instead of articles. My bad. I should change things. Okay. Fingers crossed, there we go. Okay. So hey, this is that file is showing up, so that shows that this is us editing the blog section, I mean, sorry, the index.js file. When we click categories, that should give us an error, which is perfect because we haven't built that page out yet. The same thing should happen when we click a blog post, it should give us an error because we haven't built that page out. Okay. So let's do a quick recap, but before we do that, let's just clean this up a bit. Let's take that out. Hey, this is that file. Gone. Okay. So I have a bit of a hard stop quite soon, but we'll try and get through this. The next section isn't actually what it is. There's another section that I need to add, which is creating the slack, create slack. So what we're doing right now is, this is a static web app and everything is sort of like pre-built and then rendered. Everything you see that's appearing was got from the CMS and then everything was processed in the way that I just explained it and that's how it shows up on your screen. The next thing we're gonna do is create the functionality so that whenever we click on an item, we can actually view that item, which I guess is very important, right? One page. One minute, sorry. So what we need to do next is create a single category page and a single article page. And in real-time, you'll see that being built out in the document that I shared so that you can actually copy and paste that code. But before we do that, we actually have to go back to VS Code. Sorry.

If I do anything, I need to support that before. It's the drive. Okay, so in the Pages folder, what we need to do is create a new file, sorry. We need to create a new folder, one called articles. Articles. And then we need to create another folder called categories. And inside those folders, we need to create a new file code. So I don't know. It depends in which part of the world you're from. But these, I call these square brackets. So we need to create square bracket, opening square bracket, slug. JS. And then we need to do the same thing in categories. New file, open square brackets, slug, close bracket dot JS. And what this, why we're doing this is we're utilizing Next JS dynamic pages functionality. So like I mentioned, we're still pre-building all of this. And Next really doesn't know what type of data to expect from where, right? So by doing this, we're sort of creating this template for Next to sort of parse through different data and dynamically create pages as we go along, because if we go back here, we aren't really sure of the data that's coming from the CMS. Like we don't know all the data that will come from the CMS. So we can't have like a list of literally all these pages and their slugs so that we can generate those and then serve them to the user. So we do this dynamically. Whenever we get the data, we get the slug, we process it and then we build that page out. So that's what we're going to do next. And this is probably going to be the last thing. Yeah. So this is the VS code. Give it a minute. Yep. So this is articles. So we need to click articles. And we need to paste this. Don't worry. I will share it in the doc also. There we go. And then we need to do the same thing for the word categories. Okay. Perfect. So let's go back to articles. This is exactly where we are. And let's look through exactly what we're doing. So we import React markdown. This is one of the first things that we installed because that helps us sort of convert markdown to HTML so that we can have this displayed on the webpage. And then Moment helps us with tracking or managing time in JavaScript. I have the Fetch API which helps us get data. We have layout, which is the thing that we just made. Then we use the GetStrappyMedia because we're dealing with images. Yeah, sorry. And yeah, this is what's happening. At the bottom here we have get study parts and get study props. So we're using the Fetch API again and sort of dynamically calling an endpoint based off the snag and the category. And then passing that data that we get returned as props that help us build out the page that we want. So that way we get the image URL we want whereas that, yeah, here we go, articles and categories. So that way we can still sort of display the categories we want and then display article specific data, right? Based off the slug, we're making a request to Shapi and then we get that data that corresponds to that specific page. And then we display that data. So we display article specific content, the picture of the author, the author name, where things are published and all of that stuff. So let's see. Once we save this and if we go back to our webpage, once we click unnecessary refresh, once we click an item, we should be able to see, oh, what's happening. Ooh, some chorus issues. Just a minute. Did this happen before? What I will do is I will go back to, I will stop that and I will go to, where is the file? I'll just delete this next folder and restart things again because we still have Strapi running and everything is good on the Strapi end. Shut down. Sorry, the folder name should be equal to the content type. Ah, yes, I didn't say it is though. Ah, no, that's a good point. This is articles. It should not be, yeah, good catch. Thank you so much, Victor. Great. And let's see, we have things up and running. Okay, let's see now. So everything is, everything's good here, and if we click this, and what is that? That was weird, so we have things displaying, but we have that little error for a short while, okay, that's interesting.

Click that same script, this is probably a... Okay. A request response thing. It's probably trying to render the thing before it gets the response, but that's okay. We have the blog part working, but one thing that we notice here is if we click articles, we still get that error, because we haven't set that up yet, which we will do now. So this is actually a fast stop in six minutes. So I need to rush through everything. So we'll just go back to VSCode real quick and paste the code in the category section. It's pretty much the same thing. What we're doing is importing the relevant components that we need, SEO, layout, articles, and of course, using the Fetch API because the Fetch API method from the API in the lib folder. And then we're calling this endpoint with categories for a specific spunk. And then when we're returning that, we're returning that category specific content. So it displays all the articles that are in that category. So we'll save this. And then nicely, also, it has a meta description and meta title for the category name. So you have this SEO optimized and this is something you can adapt to other places. So we should go back. Let's just, we'll refresh for good luck. And clip news. Very weird again. I think I missed, I did not name it the right thing. Yup. Rename. Yeah. Thank you. So now we should be able to. Oh, yeah, that's a really good catch. So, because of how we're naming things. Where's that? Okay. Yeah, because of how we're naming things, this folder sort of has to be the same as the content type. Otherwise things don't work. And you could see that error because I named the articles folder, articles instead of article, it was literally just an S. Under dynamic paging, the next dynamic page feature we would not let that because that's not how it works. So now if we click on tech, for example, we should see all the tech related articles. And we can click on those and yep, we can see a bunch of articles. Right, so in three minutes I will rush through the other stuff that I was supposed to get through. I would just share a link again to the thing that I was going through, HTTPS bit.ly because it has way more resources that can sort of help you. Yeah, if you wanna go through that. But like I mentioned at the beginning when I was giving you an intro to StrayPy, where were we? Yeah, the next thing that we're sort of supposed to go through was deployment. For Next.js someone asked the question, where can we deploy this? The quick answer is Purcell is really a great platform to deploy Next.js projects. Another option is something like Netlify. But I have linked here to the official documentation on deployment And PostgrePy, like I mentioned, because even though we're using the quick start and that has a SQLite database that doesn't necessarily work best in production environments. And I would suggest using something like DigitalOcean or Heroku, Azure or AWS. If you want something free, Heroku is usually the best fit and I have linked to documentation here for how to deploy Strapi to Heroku. The bonus section that I wanted to get through was, yeah, the bonus. Thank you Jorge. Thanks for coming on. And, yeah, you can upload to Azure and your own VM. I've seen people too. There's a couple of guides on how to do that and set that up also. So if you've got like your own like on-prem stuff, that's something that you can definitely do. And, yeah, previews are something that I really wanted to talk about because it's a big feature that is sort of missing from a lot of like modern CMSs. Being able to preview the content that you create before you publish it. So you enter something in here. Maybe we enter a new item here but we don't necessarily want it to show up in production. Yeah, we want to see how it will look like on the website. And what I wanted to show is how to sort of enable that with Next.js. And because I could not do that, I've left a couple of resources here. It's like a very detailed blog post that shows how to implement previews with Next.js. An intro into what previews actually look like in Next.js as well as an example application by the team at Vercel on how to use previews. And then I also have a couple of startup projects that you might want to get through and what resources that you might want to look at. And literally everything that we did today is detailed in this page. So you have the slides. If you wanna go back and look at what I was talking about in terms of headless and where it fits you have details on how to set up Strapi and Next. Plus you also have this recording. I think does anyone have any questions? I think I could take like one or two questions before I have to jump off. But thank you so much for joining the workshop. I hope it was useful. I hope you, I hope you've learned something new about the new modern way of building CMS driven applications even though it wasn't entirely the most perfect one because of time. But I think we got through some really fun stuff.

Hopefully you have an understanding of Strapi and where it fits in your stack and how you can use it and how you can get the best of it. Hopefully you've got a glimpse of how to implement it and build websites with the blog example that I just have. But yeah, thank you so much for joining and I hope you all have a great, I hope you all have a great conference.

So I'm not sure what the four I principle is. I'm not sure if you're still able to see me. No. If you can see my screen a bit better. Okay. Welcome to talk about, yeah, you can do that. We have role management. So you have someone who can build a website and we have a web browser and they can see what you're building. And then at the end of every session, you have a stand-alone speaker. And they will have a brand new body. And someone who can, I'll show that really quick here. There's something that people were confusing. There's something that a lot of people were confused by. And if you go to like administration panel, you have different roles that you can create, of the editor admin. And you can sort of decide what type of access people want. So if you look at the author, they can create read. But editors can only, you know, do certain things. So you can have someone who can only write something and they can publish it. And then they have to wait for reviews. And then you can have someone who can only publish. And then this also works really well with internationalization because you can limit who has access to different languages or can do certain things to different languages. But long story short, yes. Hopefully that helps. And again, thank you so much, everyone.