Alex Edwards

When I want to add sprinkles of interactivity to a web application, I'm a big fan of using HTMX.

Go often ships with experimental features as part of a release.

Choosing the right names in your codebase is an important (and sometimes difficult!)

Go 1.25 introduced a new http.CrossOriginProtection middleware to the standard library — and it got me wondering: Have we finally reached the point where CSRF attacks can be prevented without relying on a token-based check (like double-submit cookies)?

A few weeks ago Anton Zhiyanov published the blog post Expressive tests without testify/assert.

When I'm building a web application in Go, I prefer to use command-line flags to pass configuration settings to the application at runtime.

For many years, I've used third-party packages to help organize and manage middleware in my Go web applications.

If you've been working with Go for a while, you might be familiar with the Go proverb "don't panic".

One of my favourite features of Go 1.24 is the new functionality for managing developer tooling dependencies.

When working with Go, you have three main building blocks to help organize your code: files, packages and modules.

In almost all web applications that I build, I end up needing to persist some data – either for a short period of time (such as caching the result of an expensive database query), or for the lifetime of the running application until it is restarted.

In this post we're going to talk about how (and why!)

Whenever I start a new Go project, one of the first things I do is create a Makefile in the root of my project directory.

One of my favorite things about the recent Go 1.20 release is the new http.ResponseController type, which brings with it three nice benefits: You can now override your server-wide read and write deadlines on a per request basis.

This tutorial is written for anyone who is new to Go.

In this post we're going to run through how to use cookies in your Go web application to persist data between HTTP requests for a specific client.

In this post I'd like to talk about one of my favorite architectural patterns for building web applications and APIs in Go.

Last year I wrote a new HTTP router for Go called Flow.

When you're working on a project it's common for there to be some developer tooling dependencies.

Now that Go 1.18 has been released with support for generics, it's easier than ever to create helper functions for your test assertions.

In this post we're going to walk through how to use GitHub Actions to create a continuous integration (CI) pipeline that automatically tests, vets and lints your Go code.

In this short post we're going to discuss how to add, modify or delete URL query string parameters in Go.

Note: This post has been fully updated to reflect the new http.ServeMux features released in Go 1.22.

Recently I've been building a fully internationalized (i18n) and localized (l10n) web application for the first time with Go's golang.org/x/text packages.

When searching for examples of HTTP basic authentication with Go, every result I found unfortunately contained code which was either out-of-date (i.e. doesn't use the r.BasicAuth() functionality that was introduced in Go 1.4) or failed to mitigate the risk

One of my favorite things about the recent Go 1.16 release is a small — but very welcome — addition to the flag package: the flag.Func() function.

This is a list of things about Go's encoding/json package which, over the years, have either confused or surprised me when I first encountered them.

One of the great features of Go's database/sql package is that it's possible to cancel database queries while they are still running via a context.Context instance.

Let's say that you're building a JSON API with Go.

For the past few months I've been running a survey which asks people what they're finding difficult about learning Go.

PostgreSQL provides two JSON-related data types that you can use — JSON and JSONB.

Occasionally I get asked “why do you like using Go?”

Thanks to Andreas Auernhammer, author of the golang.org/x/crypto/argon2 package, for checking over this post before publication.

For the past couple of years I've used Sublime Text as my primary code editor, along with the GoSublime plugin to provide some extra IDE-like features.

A.K.A.

Earlier this year AWS announced that their Lambda service would now be providing first-class support for the Go language, which is a great step forward for any gophers (like myself) who fancy experimenting with serverless technology.

A nice feature of Go's http.FileServer is that it automatically generates navigable directory listings, which look a bit like this: But for certain applications you might want to prevent this behavior and disable directory listings altogether.

There are a lot of good tutorials which talk about Go's sql.DB type and how to use it to execute SQL database queries and statements.

If you're running a HTTP server and want to rate limit user requests, the go-to package to use is probably Tollbooth by Didip Kerabat.

Over the past few years I've built up a collection of snippets for validating inputs in Go.

I’ve just released SCS, a session management package for Go 1.7+.

In this post I'm going to be looking at using Redis as a data persistence layer for a Go application.

A few weeks ago someone created a thread on Reddit asking: In the context of a web application what would you consider a Go best practice for accessing the database in (HTTP or other) handlers?

This is the first in a series of tutorials about persisting data in Go web applications.

I've written a package for chaining context-aware handlers in Go, called Stack.

When you're building a web application, there's probably some shared functionality that you want to run for many (or even all) HTTP requests.

Often in web applications you need to temporarily store data in-between requests, such as an error or success message during the Post-Redirect-Get process for a form submission.

In this post I want to outline a sensible pattern that you can use for validating and processing HTML forms in Go web applications.

Taking inspiration from the Rails layouts and rendering guide, I thought it'd be a nice idea to build a snippet collection illustrating some common HTTP responses for Go web applications.

For anyone new to building web applications with Go, it's important to realise that all incoming HTTP requests are served in their own Goroutine.