<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Posts on Go Ahead</title>
    <link>https://jbrandhorst.com/post/</link>
    <description>Recent content in Posts on Go Ahead</description>
    <generator>Hugo -- 0.126.1</generator>
    <language>en</language>
    <lastBuildDate>Thu, 20 Oct 2022 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://jbrandhorst.com/post/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Go Protobuf Plugin Versioning</title>
      <link>https://jbrandhorst.com/post/plugin-versioning/</link>
      <pubDate>Thu, 20 Oct 2022 00:00:00 +0000</pubDate>
      <guid>https://jbrandhorst.com/post/plugin-versioning/</guid>
      <description>Update on Go 1.24 tool dependencies Go 1.24 introduced the -tool flag to go get and the tool stanza to go.mod. This makes tool dependencies an excellent way to manage protobuf plugins. I have rewritten this post with that in mind.
Background When working with Protobuf and gRPC, one of the first things that you as a user has to figure out is how to generate code from your Protobuf definitions.</description>
    </item>
    <item>
      <title>Serverless Application Stack</title>
      <link>https://jbrandhorst.com/post/serverless-application-stack/</link>
      <pubDate>Sat, 20 Nov 2021 00:00:00 +0000</pubDate>
      <guid>https://jbrandhorst.com/post/serverless-application-stack/</guid>
      <description>The dream of a serverless, general-purpose, portable application stack is finally a reality. TL;DR: deploy your application to GCP Cloud Run with a CockroachDB Serverless instance for persistence. Read on for a deeper dive.
Serverless compute AWS Lambda revolutionized the industry by introducing the concept of &amp;ldquo;serverless&amp;rdquo; computing to the masses. Today it lets devs and companies alike pay for exactly the amount of compute they need, down to the millisecond it takes to execute the code.</description>
    </item>
    <item>
      <title>gRPC-Web vs the gRPC-Gateway</title>
      <link>https://jbrandhorst.com/post/grpc-in-the-browser/</link>
      <pubDate>Sun, 24 Oct 2021 00:00:00 +0000</pubDate>
      <guid>https://jbrandhorst.com/post/grpc-in-the-browser/</guid>
      <description>Ever since I first started using gRPC in 2016, I&amp;rsquo;ve been interested in learning how to use it well with browser clients. It&amp;rsquo;s a common question to ask once you&amp;rsquo;ve decided that you are going to use gRPC for service-to-service and mobile app communication. Here&amp;rsquo;s this great technology that abstracts away the problems I was having when making RPC calls between my services. How do I use it for my front-end applications?</description>
    </item>
    <item>
      <title>How I use Postgres with Go</title>
      <link>https://jbrandhorst.com/post/postgres/</link>
      <pubDate>Sun, 07 Apr 2019 00:00:00 +0000</pubDate>
      <guid>https://jbrandhorst.com/post/postgres/</guid>
      <description>Most developers will have to interact with SQL at some point in their career, and often nowadays that means working with Postgres. I&amp;rsquo;ve been using Postgres with Go for a few years now and have found a couple of libraries that work really well together to make the Go Postgres experience productive, safe and fun.
TL:DR; I have created an example repo that puts all of the below into practice: github.</description>
    </item>
    <item>
      <title>The state of gRPC in the browser</title>
      <link>https://jbrandhorst.com/post/state-of-grpcweb/</link>
      <pubDate>Tue, 08 Jan 2019 00:00:00 +0000</pubDate>
      <guid>https://jbrandhorst.com/post/state-of-grpcweb/</guid>
      <description>gRPC 1.0 was released in August 2016 and has since grown to become one of the premier technical solutions for application communications. It has been adopted by startups, enterprise companies, and open source projects worldwide. Its support for polyglot environments, focus on performance, type safety, and developer productivity has transformed the way developers design their architectures.
So far the benefits have largely only been available to mobile app and backend developers, whilst frontend developers have had to continue to rely on JSON REST interfaces as their primary means of information exchange.</description>
    </item>
    <item>
      <title>gRPC Client Authentication</title>
      <link>https://jbrandhorst.com/post/grpc-auth/</link>
      <pubDate>Sun, 22 Jul 2018 00:00:00 +0000</pubDate>
      <guid>https://jbrandhorst.com/post/grpc-auth/</guid>
      <description>Introduction Best practices for performing client authentication with gRPC is a question that comes up again and again, so I thought I&amp;rsquo;d dive into a few different methods for performing authentication, using the tools provided by the Go gRPC packages.
Today we&amp;rsquo;ll explore 3 methods of authentication:
TLS Client certificate authentication Token Header authentication HTTP Basic authentication For the TL:DR; check the example repo.
Note: Go-gRPC interceptors are being redesigned, so if you implement this in your server today, you may want to keep in mind that it will change again in the future.</description>
    </item>
    <item>
      <title>Using gRPC with JSON</title>
      <link>https://jbrandhorst.com/post/grpc-json/</link>
      <pubDate>Sat, 21 Jul 2018 00:00:00 +0000</pubDate>
      <guid>https://jbrandhorst.com/post/grpc-json/</guid>
      <description>Introduction It&amp;rsquo;s often said that gRPC is tied to the Google Protocol Buffers payload format, but this is not strictly true. While the default format for gRPC payloads is Protobuf, the gRPC-Go implementation exposes a Codec interface which allows arbitrary payload encoding. This could be used for all kinds of things, like your own binary format, using flatbuffers, or, as we shall see today, using JSON for requests and responses.</description>
    </item>
    <item>
      <title>Replacing Docker Cloud</title>
      <link>https://jbrandhorst.com/post/redeploy/</link>
      <pubDate>Tue, 24 Apr 2018 00:00:00 +0000</pubDate>
      <guid>https://jbrandhorst.com/post/redeploy/</guid>
      <description>Introduction Last year I wrote a post about automating deployment of your application, all the way from git push to redeploying your application in your environment. It relied on the free version of Docker Cloud, which allowed the use of a single node for free. Of course, the idea was that you should eventually want to scale your deployment, and then you&amp;rsquo;d need to pay. As long as all you needed was a single node, Docker Cloud and its Bring Your Own Host was powerful, flexible and simple.</description>
    </item>
    <item>
      <title>Automatic TLS certificate distribution with Vault</title>
      <link>https://jbrandhorst.com/post/certify/</link>
      <pubDate>Sun, 25 Mar 2018 00:00:00 +0000</pubDate>
      <guid>https://jbrandhorst.com/post/certify/</guid>
      <description>It&amp;rsquo;s often recommended that microservice communications are encrypted, especially if they cross the public internet. Even when you control the network, whether virtually or physically, encrypting traffic can still be valuable. Lets Encrypt has revolutionized the distribution of certificates for publically facing servers; unfortunately, encrypting internal traffic often involves complicated certificate generation setups.
Hashicorp Vault is a project for storing secrets and performing authentication. It has a PKI Secret Engine backend which allows you to use it as a certificate authority in an internal public key infrastructure deployment.</description>
    </item>
    <item>
      <title>Advanced gRPC Error Usage</title>
      <link>https://jbrandhorst.com/post/grpc-errors/</link>
      <pubDate>Mon, 19 Mar 2018 00:00:00 +0000</pubDate>
      <guid>https://jbrandhorst.com/post/grpc-errors/</guid>
      <description>How to best handle errors in Go is a divisive issue, leading to opinion pieces by illustrious bloggers such as Dave Cheney, the commander himself Rob Pike as well as the official Go blog. I&amp;rsquo;m not going to tackle those opinions here, instead I&amp;rsquo;m going to talk about best practices for errors when using gRPC and Go.
The gRPC Status package The Go gRPC implementation has a status package which exposes a nice simple interface for creating rich gRPC errors.</description>
    </item>
    <item>
      <title>So you want to use GoGo Protobuf</title>
      <link>https://jbrandhorst.com/post/gogoproto/</link>
      <pubDate>Mon, 19 Feb 2018 00:00:00 +0000</pubDate>
      <guid>https://jbrandhorst.com/post/gogoproto/</guid>
      <description>Introduction In the Go protobuf ecosystem there are two major implementations to choose from. There&amp;rsquo;s the official golang/protobuf, which uses reflection to marshal and unmarshal structs, and there&amp;rsquo;s gogo/protobuf, a third party implementation that leverages type-specific marshalling code for extra performance, and has many cool extensions you can use to customize the generated code. gogo/protobuf has been recommended as the best choice of Go serialization library in a large test of different implementations.</description>
    </item>
    <item>
      <title>I was invited to a meetup</title>
      <link>https://jbrandhorst.com/post/budapest/</link>
      <pubDate>Sat, 10 Feb 2018 00:00:00 +0000</pubDate>
      <guid>https://jbrandhorst.com/post/budapest/</guid>
      <description>Introduction After my presentation at the Go London meetup I was approached on Gophers slack by a gentleman from Hungary called Máté Gulyás. Máté is one of the organisers of the Budapest Go Meetup, and was reaching out to me to ask if I would like to come down to Budapest and deliver a talk for the meetup. I was delighted with this invitation and promptly accepted and we started planning.</description>
    </item>
    <item>
      <title>Client side streaming in gRPC-Web</title>
      <link>https://jbrandhorst.com/post/client-streaming/</link>
      <pubDate>Sun, 17 Sep 2017 00:00:00 +0000</pubDate>
      <guid>https://jbrandhorst.com/post/client-streaming/</guid>
      <description>In a previous post I introduced my open source project to bring GopherJS bindings to Improbable&amp;rsquo;s gRPC-Web client. I&amp;rsquo;m happy to say that the initial goal of supporting all features of the gRPC-Web client has been completed. I was initially going to leave it at that and wait for client side streaming to land in the WHATWG Streams API Standard, and subsequently added to the official grpc-web spec and probably the gRPC-Web client, but then I was sitting at the GolangUK conference and I had a brain wave.</description>
    </item>
    <item>
      <title>Advanced CircleCI docker testing</title>
      <link>https://jbrandhorst.com/post/circleci-docker-compose/</link>
      <pubDate>Fri, 04 Aug 2017 00:00:00 +0000</pubDate>
      <guid>https://jbrandhorst.com/post/circleci-docker-compose/</guid>
      <description>In a recent blog post I talked about automating the testing of an advanced GopherJS library using a combination of QUnit, Ginkgo and Agouti. That allowed me to run a complete integration test suite against my library by automatically spinning up browsers and pointing them at my QUnit GopherJS page. This was a great start, but after running it a couple of times we find that there are several problems:</description>
    </item>
    <item>
      <title>Chunking large messages with gRPC</title>
      <link>https://jbrandhorst.com/post/grpc-binary-blob-stream/</link>
      <pubDate>Fri, 14 Jul 2017 00:00:00 +0000</pubDate>
      <guid>https://jbrandhorst.com/post/grpc-binary-blob-stream/</guid>
      <description>One of the gotchas of using gRPC is that it was not designed to transport large messages in one chunk. The default max message size is slightly arbitrarily set at 4MB today, and while it is possible to configure, that kind of behaviour might lead to a slippery slope scenario of ever increasing max message sizes. So what do we do when the message size is too large? We chunk the data into smaller pieces and stream it, using the gRPC streaming methods, naturally.</description>
    </item>
    <item>
      <title>Throttling resource intensive requests</title>
      <link>https://jbrandhorst.com/post/go-semaphore/</link>
      <pubDate>Fri, 14 Jul 2017 00:00:00 +0000</pubDate>
      <guid>https://jbrandhorst.com/post/go-semaphore/</guid>
      <description>Sometimes when you&amp;rsquo;re writing a server, you&amp;rsquo;ve got a function that consumes a lot of memory while running, or some other resource, and you might be worrying that a sudden burst of requests could crash the server, since gRPC by default will just spawn another goroutine to handle any incoming requests, oblivious to the danger. In these situations, it can be useful to implement some custom request throttling. Here I&amp;rsquo;ll show an easy way to accomplish this with the use of a Go channel.</description>
    </item>
    <item>
      <title>GopherJS Integration Tests</title>
      <link>https://jbrandhorst.com/post/gopherjs-integration-tests/</link>
      <pubDate>Tue, 11 Jul 2017 00:00:00 +0000</pubDate>
      <guid>https://jbrandhorst.com/post/gopherjs-integration-tests/</guid>
      <description>Recently I found myself wondering how I was going to test my new GopherJS gRPC-Web bindings. Writing tests was something I had been waiting with until I had something working, mostly because I had no idea how I was going to meaningfully test GopherJS code that relies on interactions with JS and the reponses of a server.
I have in the past made a small contribution to the GopherJS websocket repo, and found myself impressed with the extensive tests written for the repo.</description>
    </item>
    <item>
      <title>gRPC-Web with GopherJS</title>
      <link>https://jbrandhorst.com/post/gopherjs-grpcweb/</link>
      <pubDate>Tue, 20 Jun 2017 00:00:00 +0000</pubDate>
      <guid>https://jbrandhorst.com/post/gopherjs-grpcweb/</guid>
      <description>In a previous blog series I&amp;rsquo;ve talked about how to work with a gRPC backend from the GopherJS world. It relies on the gRPC-gateway which is a great piece of tech, but unfortunately carries a couple of downsides:
Clients don&amp;rsquo;t know what types are used - the interface is HTTP JSON. This can be somewhat mitigated with the use of swagger generated interfaces, but it&amp;rsquo;s still not perfect. The interface being JSON means marshalling and unmarshalling can become a significant part of the latency between the client and the server.</description>
    </item>
    <item>
      <title>Auto-deployment of your app from Github</title>
      <link>https://jbrandhorst.com/post/app-deployment/</link>
      <pubDate>Sun, 04 Jun 2017 00:00:00 +0000</pubDate>
      <guid>https://jbrandhorst.com/post/app-deployment/</guid>
      <description>Update Docker Cloud is being discontinued. For an alternative easy app deployment, check my new post on automatic app deployment. Furthermore, I would nowadays recommend Hetzner Cloud over Scaleway. Scaleway was running out of instances last time I tried using them, and Hetzner&amp;rsquo;s web console is much better than Scaleways.
Old post preserved below.
Introduction Yesterday (!) I asked in the Gophers slack for recommendations for deployment of static Go binaries, as I was in the process of deploying a demo for another blog post I&amp;rsquo;m working on.</description>
    </item>
    <item>
      <title>Go Protobuf Tips</title>
      <link>https://jbrandhorst.com/post/go-protobuf-tips/</link>
      <pubDate>Tue, 18 Apr 2017 00:00:00 +0000</pubDate>
      <guid>https://jbrandhorst.com/post/go-protobuf-tips/</guid>
      <description>I&amp;rsquo;ve had my fair share of dealing with proto files in go (and to some extent JS), so I thought I&amp;rsquo;d share some stuff I&amp;rsquo;ve learnt the hard way by working with proto files.
Protoc include paths The protoc include paths can be pretty confusing, so I&amp;rsquo;ll give a few examples of how to use it properly.
Just include the current directory protoc requires that the files referenced are in the include path, so if you&amp;rsquo;re referencing files relative to the current directory, you&amp;rsquo;ll need to specify -I.</description>
    </item>
    <item>
      <title>GopherJS Client and gRPC Server - Part 4</title>
      <link>https://jbrandhorst.com/post/gopherjs-client-grpc-server-4/</link>
      <pubDate>Fri, 14 Apr 2017 00:00:00 +0000</pubDate>
      <guid>https://jbrandhorst.com/post/gopherjs-client-grpc-server-4/</guid>
      <description>Putting it all together As we touched upon earlier, we generate a package from the generated JS (meta, right?), which can be served from the server. We&amp;rsquo;ll create a new file, main.go, in which we can spin up a server, serve the frontend and the gRPC backend.
Much of the logic in this file is inspired by the excellent blog post put together by Brandon Philips over at CoreOS. We&amp;rsquo;re using his elegant solution to serve both the HTTP API and the gRPC API on the same port.</description>
    </item>
    <item>
      <title>GopherJS Client and gRPC Server - Part 3</title>
      <link>https://jbrandhorst.com/post/gopherjs-client-grpc-server-3/</link>
      <pubDate>Thu, 13 Apr 2017 00:00:00 +0000</pubDate>
      <guid>https://jbrandhorst.com/post/gopherjs-client-grpc-server-3/</guid>
      <description>Implement the client GopherJS can be used in a couple of different ways, and there&amp;rsquo;s a couple of different bindings to many popular JavaScript frameworks. The GopherJS wiki has some great resources.
I tried a couple of different ones and ended up using the VueJS bindings because it made it easy to prototype things quickly. I hear VueJS works well for many JS evangelisers out there, but I&amp;rsquo;ve only used it with small projects.</description>
    </item>
    <item>
      <title>GopherJS Client and gRPC Server - Part 2</title>
      <link>https://jbrandhorst.com/post/gopherjs-client-grpc-server-2/</link>
      <pubDate>Wed, 12 Apr 2017 00:00:00 +0000</pubDate>
      <guid>https://jbrandhorst.com/post/gopherjs-client-grpc-server-2/</guid>
      <description>Implement the server I like to start by creating a struct and write a simple definition that&amp;rsquo;ll immediately fail to compile.
package server import ( &amp;#34;github.com/johanbrandhorst/gopherjs-grpc-websocket/protos/server&amp;#34; ) type Server struct{} var _ server.MyServerServer = &amp;amp;Server{} This won&amp;rsquo;t compile, because the Server struct does not implement the server.MyServerServer interface. But it&amp;rsquo;ll also tell us what we&amp;rsquo;ve got left to implement. So lets implement the server methods:
func (s Server) Simple(ctx context.Context, _ *empty.</description>
    </item>
    <item>
      <title>GopherJS Client and gRPC Server - Part 1</title>
      <link>https://jbrandhorst.com/post/gopherjs-client-grpc-server-1/</link>
      <pubDate>Tue, 11 Apr 2017 00:00:00 +0000</pubDate>
      <guid>https://jbrandhorst.com/post/gopherjs-client-grpc-server-1/</guid>
      <description>Create the protobuf interface We&amp;rsquo;ll start by creating a folder for the package we want to create. Lets call it server. Next we type up a .proto file to define the interface between the server and the client. We&amp;rsquo;ll have to include some extra proto annotations in order to have the gRPC-gateway generate the translations methods we need. Lets define a simple service with a single HTTP GET endpoint:
service MyServer { rpc Simple(google.</description>
    </item>
    <item>
      <title>GopherJS Client and gRPC Server - Introduction</title>
      <link>https://jbrandhorst.com/post/gopherjs-client-grpc-server/</link>
      <pubDate>Mon, 10 Apr 2017 00:00:00 +0000</pubDate>
      <guid>https://jbrandhorst.com/post/gopherjs-client-grpc-server/</guid>
      <description>I&amp;rsquo;ve been using gRPC and Go a lot in the last year. At Cognitive Logic every one of our backend services is implemented with Go and gRPC, and it enables us to abstract away most of the complexities of networked micro services and keep interfaces typed and well defined using Google protobuffers.
I really enjoy using both, but sometimes I need to write a frontend to a web server and I despise writing Javascript.</description>
    </item>
  </channel>
</rss>
