Gatsby + Wagtail + Netlify (with a little GitPod) – Dawn Wages

Speaker 1: Hey all. My name's Don League. And we'll be talking today about Gatsby, JS, Flagtail, Netlify, and a little bit of Gitpod. It is definitely a new tech kind of sandwich. Clearly I like new shiny things. So I'm excited to just give a brief overview on what I did with the Sex Act and also Feature Talk just got accepted to PyCon Australia. talk so I'll be giving a revised version of this talk probably going in more in depth at PyCon Australia so hopefully I see you there

Speaker 1: So as I mentioned, I'm Dawn. You can find me on Twitter. I uh used to tweet too much, now I tweet almost too much at Don We just says. Um, I am a WebTale Corps team member. I just recently joined the team and I am around an intimidating amount of brilliant people on that team. They're amazing and they're just so kind all the time. So it's um it's kind of an honor to be on that team. Um and so this is one of the first kind of contributions that I've really done um on as a core team member. I hope to do more things from this topic and a lot of Wagtail slash React Headless Wagtail type things for the beginner and intermediate level

Speaker 1: with publishing content and blocking. So that'll be exercising soothing muscles for me there. Hope to see you on some of that content. If you have suggestions on types of content or partnership or things like that, I'm I always love making new friends and connections. Beyond that, I am a developer at TROC Software, a small Django shop. Again, I mean I love working with awesome people. It's important to me. from our rules. So I'm in good company there. And I also am a Django Romia consultant. So my company is called Rugby Street Designs. I live in Philly and got acclimated and got introduced to Django in Philadelphia at DjangoCon

Speaker 1: 2016. and I came through Django Girls. So I am proof that it works. I am a dog mom and a queer woman of color and I'm very proud of both And uh that's my pup. So uh the meat of the talk is about Wagtail and Gatsby in future versions of the talk. I'd like to also get more into the two other bing words, uh Netlify and Gitpod. There's some new developments there just to make things easier. What I love is being able to start with very little experience or just start from nothing and being able to build an app or a site

Speaker 1: very very quickly that's something that both uh Django and React and then their and extensions of those Wagtail and GASB really pride themselves on is being able to start from very low. So the goal of the experiment was to try out some shiny new things. As an independent consultant, a lot of times and also with TROC, we're starting new pro um projects where we have small and medium businesses We want to be efficient, but we don't want to skip um skip out on any of the uh really cool uh features of some of these uh larger frameworks that are really sustaining like entire companies. I mean we have an entire company that's built off of React.

Speaker 1: So the current version is of this talk is a short introduction to Gaspy. js to a Wagtail audience, so I won't be speaking very much on uh benefits of wagtail and the cool things on wagtail why we why we love it um that that should be more heavily in the PyCon Australia Talk. And it'll be a primer on uh why they're together and how to get started. So So Gatsby, uh for those who don't know, is a progressive web app generator. Um it is um You can do full stack on on Gatsby. One of the things that it uh uh touts itself for is being able to handle

Speaker 1: a bunch of different data sources. Just like Wagtail, it is a plug-in -focused uh ecosystem. Um so we really can integrate it with tons of things and they have tens of thousands of users and a very, very active community. I'll get more into that later as well. And is very good of a project for small and medium medium projects. Just if you want to whip something up quickly without sacrificing design, performance, hosting cost. So one of the benefits of having a um web app generator or a static site generator if you're more familiar with that terminology. Gaspy it's it's all kind of hairy and uh it's a bing word more so to make sure you're

Speaker 1: You're recognizing that uh with correct with a progressive web app you're not sacrificing the in the functionality. Uh you still have that uh JavaScript and it does feel um more of a modern approach when you are presenting that app to the client side. And so what a web app generator will do, it'll take the code that you write in whatever language So if you're familiar with Jekyll or Haskell , Gaspi is written in uh react and then it will distill all of that um and then uh present it to the client side it is incredibly efficient and one of the also the benefits is SEO. React is known for not being very good with uh with SEO

Speaker 1: but because it is a static site generator um you will have Google um uh scraping and traversing the site um in a way that's just like a flat HTML site, um not highly performant. So typically we're making calls from the client to the server in the progressive web apps. So the static S site will have it distilled down and rehydrate. So both Gaspany and Wagtail are open source frameworks. And we'll, I mean, there'll be more talks today and tomorrow and just brilliant people on here that can talk more about the awesome features of Wagtail. um like photo identification and like auto photo tagging, just really cool talks that I've seen

Speaker 1: over the years, a lot of which are on YouTube. So as I mentioned, there's excellent, really, really active communities. Both frameworks emphasize a smooth developer experience. For example, and I'll get more into this as well, it all ties together, but their Gatsby CLI is just incredibly easy. you say gets the new project name and you use the source of the project and it automatically creates the file structure that you need, very similar to other very intuitive modern CLIs. And Wagtail proports this very similar experience with

Speaker 1: focusing on how well the developer can get up and running and how quickly and how intuitive. I mean the best the best code is readable code. Both are very accessible, plug-in architecture, and both top being very secure and working on maintaining high levels of security. So my background in approaching this site is not really an expert on all of these technologies. My main background is in Django and React. And then more recently in the past year I've stuck those two together and done headless wagtail with not ex uh uh taught myself as an expert in by any means. So uh this is definitely a primer and uh what will come down the road will be uh more

Speaker 1: intro applications to um how to start. So I've never deployed to Netlify before. Mostly I do um like Heroku or I am a user experience developer developer and we have DevOps teams. And I'm also a beginner with Gitpod, but everyone's a beginner with Gitpod. As we get into it, I'll explain what Gitpod is for those who don't know, but it's a very new feature that also enhances developer experience. And started from scratch. It's a theme. Um so We don't want to have to compromise with some of these applications, so starting quick, going fast, having it look beautiful. We don't want to compromise between a hard-coded

Speaker 1: static site, which is highly performance, and a full CMS. So I'll give you the punchline early. The experiment was somewhat of a success. And then future versions I'll be able to share some code. and things like that but no code will be shown today. Um I also won't be taking questions today but I will be around in the Slack channels and I'm I'm a very friendly person so reach out. I like you guys So why would we do headless wagtail? And we've had that question a little bit in the previous talk. theoretical debate. I enjoy it because I did come from the JavaScript background. I do like the progressive web app experience and um

Speaker 1: the component architecture you can have atomic design and uh really recycle and reuse a lot of components especially as uh projects get more complicated but even the more simple ones if you it's a great framework to be able to think about how you're going to design your site as a developer, what goes where and what information needs to go where and how. And it is an efficient way of doing it Um headless uh does allow for um uh that same backend API structure to be used. used for lots of different applications and as the emergence and accessibility of jumping into the Internet of Things that's um a positive for why going headless.

Speaker 1: I mean and I'm working on a project now where we're just about to uh we're thinking about going uh React Native and having the same Django Django backend. Shout out to Caleb who runs Learn Wagtail and has a ton of headless Wagtail content on his site and on YouTube. Uh so why Gatsby? So I have a screenshot to the left of a um of their starter page. Starters are what I mentioned earlier where you do Gatsby new site name and then the and the link and it will

Speaker 1: have really great contributions for starter pages. I would don't tout myself as the designer or the one with the design eye. It will as somebody who wants to start from something and have something really pretty very quickly um you 're able you're handed a a a site that like really can look very beautiful and clean and modern um from a jump. So key features of React are all available with Gasping. You're not sacrificing any of that. It is written in React and with certain plugins you can use use any ECMAScript version and as you are deviating from the normal CRUD application,

Speaker 1: create, read, update and delete. you have Python and React at your fingertips to be able to integrate that um uh like you would otherwise with a more uh with an application that's more custom and has more heavy lifting More beautiful designs, uh just kind of giving you a little bit better of a close-up. And if you can see down here in the bottom, it's GASPY new, GASPY starter profile, Kara, and then you have the GitHub link and it just starts from source. And they have a very easily accessible website to kind of look over it and

Speaker 1: to search for them. So uh that's V J S. Um Does have multiple data sources, CMS markdown data types are where we can we can gather all the sources and it gives to one location. So I've spent more time with uh Django Rust Framework than I have with RathQL. They are different. They uh one is a uh GraphQL is a runtime um uh search tool and also has uh really, really

Speaker 1: flexible uh ability to query through your data and data endpoints. Django West framework, I mean, has really, really intuitive and great great way of looking through your data and seeing um display pages through the the client side as well um but doesn't have that um live runtime querying ability. I think that was probably the biggest barrier for me is getting comfortable with GraphQL still think I'm I'm quite there um but it is uh when you're adding the two to that together you have GraphQL on top of your on your um Django site um and it and it gets a little weird, not bad, just

Speaker 1: just interesting. And I'll I'll be showing a little bit of code later to show to show some uh to get you a little bit more acclimated But they don't have a complex server setup. It is very scalable, as I mentioned, and they have code sandboxes throughout their documentation. um to try things out and and get you at um get you jumping in quickly. So here's a screenshot of um GraphingQL, uh which is where you can uh Poke around and look at what the uh endpoints look like of your uh data structures and things like that.

Speaker 1: So here are some resources. They're just links. I will show this again at the end. It's the last slide. That's one of the challenges with tackling this project is that the resources that are available links that are available with GraphQL and Wattale are very few. I mean they're both very new frameworks, so we're expecting this as a new territory. That's the point of the talk. And I'm hoping to contribute to that space. Um and um there um have a level of assumption that doesn't uh that's not quite beginner, more like intermediate, um, but's not uh doesn't need um advanced level knowledge you're not reinventing uh the wheel

Speaker 1: necessarily. Uh both I would highly recommend both GaspiJS and Wagtails original documentation. They put a lot of work into it, both frameworks. So I always start there. But we also have a lot of activity on the Wagtail channels. So I put in a few of my the channels that I look at frequently for Gatsby and Wagtail and Headless. But we're really everywhere, big community. Graphene Django and Wagtail GraphQL API. are what you need to translate Wagtail's custom models to your GraphQL schema.

Speaker 1: And that added a little extra just a learning curve not familiar with it originally um and uh I'm more familiar with just graphing Django um and figuring out how GraphQL is going to curate query. I just needed to learn more about how Wagtail decides to set up their the models that they they provide for you and does a lot of work and thought with how how that's displayed. So here's how I set up my project. Um this is by no means the um definitive way of doing it um but I have my

Speaker 1: API folder with my uh initialized at the API app and I have um the schema in there to define uh that we are going from Wagtail to uh GraphQL. This is just a regular Django blog app and I will go in here we go on the far right is the um is the graph uh excuse me the gap gasby front end block and components

Speaker 1: I hope this is able to be read, but the point is more on the right. This is the Gatsby config. js. If you want to look at the previous slide. That speedconfig is within the source file for the front end. And this is how it structures any of the plugins that you're going to have. And there are thousands of plugins with uh thousands of users and very, very active repositories. So Here's just a few. I mean I it was just kind of a smathering of ones. I mean I come from an e-commerce background. I started as a project manager at an e-commerce work.

Speaker 1: So I'd like to get back back into that. I don't do a lot with it more. But finding fun frameworks that interact with e-commerce. tools are cool. Gaspi has shop Shopify, which is really popular. Google Analytics, things like that. Here is an example of the blog page. I'll skip back to the file structure to show quickly blog page is within the pages folder but the I mean not necessarily but uh the pages folder of the the original source file What we are doing is creating

Speaker 1: this is this is very React. We are importing React. We are have prop types. This is so if your eyes start crossing with all the JavaScript, I understand We are creating a component and then we also are explicitly using SEO components that were Part of the starter application that you can use. They have some in the some of the starter applications and just make it kind of explicitly shown to emphasize SEO and accessibility. If you see that we're passing in this data, we are defining the pages. This is how Wagtail has their data structure for the Wagtail Core pages. We are rendering

Speaker 1: each of these pages. And these are the this is the dynamic title, title heading, things like that. This is a list, and we are returning this layout with With base page in here This is the blog page on the left, more of the blog page, and this is on the right Gatsby node JS. So Gatly node on the right, these is this is where they create all of the pages together.

Speaker 1: This is where we are also doing the initial query for all of our data. This makes this part of what makes it highly performant is that it it grabs the data that you're looking for. I have very a small bit of data because it's just just a uh like a demo site right now. Um but this is uh what what gathers it all for you and then has it on the client side uh ready to use And does not have to go back and forth between the client and the server. And on the left, we are doing a similar GraphQL query, but it is only for this. Particular base page.

Speaker 1: I might need to speed up a little bit. Uh this is more of that spee node uh JS. Uh so uh Yeah, this is just focusing on that center part where what I what trips me up and what I had the most trouble with was navigating GraphQL and understanding how that relationship works so that this zooms in on just that portion. Um, I'm back to my um app setup. So Did it work? Um yes. Was it kind of wonking a little bit um hard for me to to link the two together? Yes. Um, it is not for the absolute novice and the absolute beginner, but it is something that can

Speaker 1: when there's more boilerplate codes or more demo codes and more um um um more blog posts regarding the subject, it definitely could ease uh could be a beginner and intermediate topic. There is no reason it it shouldn't be. It's just new territory. I think that in the future that I will continue to be using using it. I have a project in the works that will just kind of spit out more pages like this and the it will not be cost prohibitive for myself to develop it or for my clients to be able to host it Gitpod. Gitpod 's really cool. I'm not going to be able to talk a lot about Gitpod

Speaker 1: , but Blacktail team has done some work with um uh with having their own wagtail git pod and I'd like to have a similar one that has a Wagtail Gatsby Git pod. And so what it essentially does is when you go to your uh repo on GitHub, there is this blue button and it opens up this in the browser IDE. It's basically like the VS Code in your browser. and it automatically from the um from Docker requirements in the Git um Gitpod YAML file will create all of the requirements that you need to set up the project. This is really, really cool if you want to continue to um if you're teaching

Speaker 1: or if you're doing code reviews. Each of the workspaces, they call them workspaces, are will remain open for about two uh for two weeks. Um And so that is a good and a bad. I mean they are made to be temporary. If you forget about it, you lose your work. However, it does allow you to um contribute code back to the original code source and things like that. So it's I mean it it's just a different way of um of contributing and It's kind of cool. But you can do this development environment for any GitLab, GitHub, or Big Bucket project. And if you want to just jump in and start playing in a sandbox environment, it allows you to do that. I mentioned you can implement new features, merge a fix, troubleshoot.

Speaker 1: And just like VS Code, it has its own Linux terminal and based off the Docker images. But and you can have up to 16 workspaces, which is really cool. So here is the Gitpod YAML file, and this is what the Wagtail Gitpod is doing. And I mean it's even creating an admin user for you with the password change made. Uh so deploying with Netlify is

Speaker 1: It's uh similarly easy uh to a lot of the other tools. I mean, this is all based on trying to make your user experience going from zero to deploy easier. And Tom Dyson has um have code uh for uh the Wagtail Netlify connection your uh You are installing the Netlify CLI and then PIP installing Blacktail Netlify. There's a few little configurations within your installed apps and you run your migrations and then it's very easy to deploy with Netwify and and Wagtail. So

Speaker 1: this was not a true blue case study. A true case study should be coming forward where I can kind of look at some of the pain points that I had and where my uh clock kind of maxed out a little bit more than I wanted it to, but it's definitely a shiny new thing. So it is highly performant and really good for crud sites, working quickly and the I mean who doesn't think the GraphQL playground is kind of cool? debatable on whether or not it's necessary when we have other um awesome tools with with Django, but um it's not quite straightforward yet.

Speaker 1: So the next steps I'm going to be publishing Gassy Wagtail starter on Gitpod. There will be a more detailed talk at Hycon Australia blog posts and a demo app to companion the blog posts, all of which are a work in progress. I wish I could have shown them to you today, but now we are connected, now we're friends, now you have my Twitter. So um It 'll all be posted and available hopefully soon this summer. Yeah, that's it. That's my talk. I appreciate the time. It was great meeting everybody.

Speaker 2: Great. Thanks, Don So uh I have a question if you're willing to accept questions. about that. Sure.

Speaker 1: Most of the questions, I mean, I gave the context of what I know. So shoot.

Speaker 2: Okay. So uh Just one question. Do you think that by going this route with Gatsby, that it gives you a little bit of flexibility in terms of what the back end could be? Or is it pretty tightly coupled with Wagtail at this point?

Speaker 1: It's it's really tightly coupled and any change that you would make to the back end would have you uh doing more work with the uh uh Gaspi config. Um and so just any it's You kind of have to figure out what you want beforehand and then make those changes. And if there are going to be a lot of iterations through what your data is going to look like, it may not be the best option.

Speaker 2: Um and then I'm just seeing a question come in too uh from Timmy Smalls. Uh have you ever used Wagtail Grapple? Uh it's a Wagtail wrapper around graphene that allows for easy integration.

Speaker 1: Um, I haven't. Anyone want to speak to maybe Wagto Grapple if they had? Or in the chat. Okay.

Speaker 3: But In its current state, it's it's pretty handy for getting quickly up and running with uh models and GraphQL if you haven't done that kind of setup before. Um We talked about using it at the city of Austin, but we had kind of already rolled our own sort of graphene Django implementation, and I think the like time costs of transitioning wasn't quite there. It definitely has a lot of promise. I think we could definitely use contributions. It might be kind of fun to fork off the Gatsby starter and see if we could If I could wrap around it with Grapple as an example. I'm not sure how performant and mature some of the GraphQL stuff is on the graphene side and on the grapple side at like scale.

Speaker 3: That's been like a worry of mine, but of course all of us working together on a solution is like a better shot at addressing those than each of us off doing our own thing anyways.

Speaker 1: Cool.

Speaker 4: Yeah. If I may um also uh say something. I uh I've also worked with um uh Bactio Grapple for uh for quite a while now and it's proven really useful to be able to query all the um Oh, the the typical uh Wagtail models. So for example, images and pages. And uh I use it in a couple of sites and I have um implementations for my stream fields, for example. So I can really um yeah, it it's really useful uh in conjunction with Wagtail. Um and I generally use um graphene on the side for everything that is not directly wagtail related so if it's just a regular uh Django model I will go with uh graphene and like uh mix them up together

Speaker 1: Cool. Thanks. Well, I think that's my time. Uh thanks everybody. I appreciate it.