Creating a Go SDK for Buildable.dev (Part 1)

Introduction

Message handling across distributed applications is an often times complex and difficult engineering challenge. The advantage of good messaging is quick integration between lots of disparate services be it for e-commerce, devOps or even for analytics but keeping these different systems in sync is a serious challenge.

There are plenty of options in this game be they built in house on-top of solutions like Kafka, or more generic open and closed source solutions.

After coming across a new offering in buildable.dev, and noticing it only supports a NodeJS SDK I decided to try my hand at building another SDK in Go, a favourite language of mine, and an up-and-coming solution for writing micro-services which perfectly fits the use case of a real-time event stream solution like Buildable.

Buildable's Events

Buildable provides a simple interface for creating and listening to events, at it's most basic we can:

• Emit new events
• Listen for events being emitted (transact)

Event emissions

In the buildable world, each event has a name and an associated JSON payload, for example:

{ 
  "event": "my-first-event",
  "payload" {
    "hello": "world"
  }
}

we can emit a basic event through CURL with the following command:

curl --request POST \
 --url https://events.buildable.dev/emit \
 --header 'Content-Type: application/json' \
 --header 'X-Buildable-Secret: SECRET' \
 --data '{
  "event": "my-first-event",
   "payload": {
    "salutation": "Hello World!"
  }
}'

which will get nicely picked up on your buildable dashboard.

Transactions

On the other-hand, we can consume these events and action on them. Simply put, we're registering an interest in this event and consuming it's payload in our application in order to react to data changes somewhere else, be it our own microservice or through another connection to an application like stripe. In the Javascript SDK this is done like so:

client.on("my-first-event", async ({ payload }) => {}, { 
  platform: "custom", 
  label: "demo",
})

Seems simple enough right!

The meat and potatoes

So, we have the rough idea of how this SDK should work. In essence, we want to be able to create a client that can:

• Emit events based on actions
• Register for events
• Action based on the registered events
• Deregister from events if need be