Module 1 - Introduction
1. Welcome to the course2. Why Go3. Why start and build a blog?4. What about React/Vue/Angular?5. Getting setup and source filesModule 2 - Tech Stack Walkthrough
1. Introduction to Golang Part 12. Introduction to Golang Part 23. Introduction to Golang Part 34. Structuring Golang Applications5. Templating with Templ6. Just enough interactivity with HTMX7. Getting started with postgres8. Servers, routers and endpointsModule 3 - Creating the MVP
1. What are the minimal requirements?2. Doing some initial plumbing3. Embedding static assets4. Creating our first views5. Tailwind & Utility-first CSS6. Styling the Landing Page7. Styling the Article PageModule 4 - Managing Content
1. Choose your own adventure2. Writing in Markdown3. Parsing Markdown to HTML4. Frontmatter and Meta Information5. Making our code examples look nice6. Adding error pagesModule 5 - Adding the Database
1. What is a Migration?2. Our first migration: articles table3. Creating the Database Layer4. Showing the Latest Posts5. Slugs and Human Readable URLsModule 6 - Managing the Blog
1. What are the minimum requirements?2. A new layout approaches3. Introduction to authentication4. Our second migration: Users Table5. Storing passwords securely6. Authenticating users Part One7. Authenticating users Part Two8. Remember me/Forget me9. Managing posts using a hypermedia API - Part One10. Managing posts using a hypermedia API - Part Two11. Managing posts using a hypermedia API - Part Three12. Managing posts using a hypermedia API - Part Four13. Implementing CRUD For Articles - Part One14. Implementing CRUD For Articles - Part Two15. Implementing CRUD For Articles - Part Three16. Implementing CRUD For Articles - Part Four17. Flashing Ourselves/Providing Visual Feedback - Part One18. Flashing Ourselves/Providing Visual Feedback - Part Two19. Flashing Ourselves/Providing Visual Feedback - Part ThreeModule 7 - Adding Subscribers
1. What are the minimum requirements?2. Expanding the database: Tokens & Subscribers3. Creating the token and subscriber models - Part One4. Creating the token and subscriber models - Part Two5. Creating the subscription form6. Saving and verifying subscribers - Part One7. Saving and verifying subscribers - Part Two8. Saving and verifying subscribers - Part Three9. Emails and Clients - Part One10. Emails and Clients - Part Two11. Emails and Clients - Part Three12. Our fifth migration: Tokens Table13. Email validation view14. Email validation tokens15. Sending validation emails with SES16. Making it all come togetherAdding Subscribers
Saving and verifying subscribers - Part One
Summary
Coming soon.
Transcript
Alright, so we have our form in place. Now we just need our handlers. We're going to be needing three handlers to complete the flow that we have designed. So we need one to actually create the subscription. We need one to verify the token. And we need one to generate a new token for whenever the subscriber either didn't verify the email in time or just need a new one. Something went wrong, right? So three new controllers. So we're going to jump into controllers, go to the bottom here, and I'm just going to steal this and say subscriber create. And in here we're going to say type subscriber create payload struct where we have the email, the string, it's going to come from our form. So email, there we go. Pass the payload. And this is again, we have done this before, so nothing new happening here. We're just taking the request and then binding the data to our payload variable. There we go. To our payload variable. And if we have any errors, we just return the views subscription failure response render again, render or go. Now, since we are going to be creating a resource and also relying on a third party service when this flow is complete, because we will need to send an email and we might store the user, we might store the token, but the email might not get sent because something, something with our email provider, right? So it's good practice here to use a transaction. So we only store the subscription, only store the token if everything else succeeds. So let's create a token or so let's create a transaction, which is really straightforward. We just use our pool and say begin, pass the context, and then we might have an error. So if error doesn't nil, then let's just return this. Okay. We also need to, we could technically, we need to call rollback if anything goes wrong, so this thing doesn't get committed to the database. What we can do, because we use the pdx libraries, we can call defer rollback request ctx, there we go, request context. So now, if we for any reason return an error or don't call commit on the transaction, it will just roll back all the changes and we will not have the database records being stored. So this is just the setup for doing transactions. Then we're going to say new subscriber on error. We're going to use our model and our new subscriber, there we go, pass the necessary data. We need to fill in the payload and my LSP is messing with me right now. So here we're going to say and there we go, fill in and it's not going to be of email, it's going to be payload email. If we have an error, one more time, we just return the subscription failure response. If we do not have an error, we're going to create a token with our models new token here. Again, we pass context, we pass the dbpool and then we pass the data or the payload data. Exploration, so let's give them I think 48 hours is a decent time frame for validating your email. So now this one will expire 40 hours from now. We also need to provide some meta information. So we are on models and resource subscriber, which maps to our subscriber table. The resource ID is going to be new subscriber ID and finally the scope will be models scope email verification. Right and one more time, if we have an error, let's just return the failure. If not, then we say views, subscription, success response, render, our render args and there we go. So now of course we have some errors here, we need, let's just have this be a blank for now. So this is how our subscription create controller works. We accept an email from the form submission, we create a transaction, we create the user, we create the token, we add some meta information so that we in the token can unmarshall this data from, are we going to store this metadata as JSON, we're going to unmarshall it out into a structure we know and then we can update the subscriber to have a status verified. Finally, we send an email or we generate an email, we're going to get back to that soon. If that goes well, we commit and return a response message to the subscriber.