DEV Community: Matthew Henry

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

Matthew Henry — Tue, 01 Nov 2022 17:00:00 +0000

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

When it rains, it pours.

Matthew Henry — Wed, 13 Feb 2019 15:46:54 +0000

When it rains it POURS

TLDR: ALWAYS, ALWAYS, PICK THE DATE FURTHEST AWAY FROM TODAY

The drought

Having started my second year in Computer science in college I realized that I have to get some form of work experience in the city to keep ahead of the game (and going home for another summer seemed a little un-attractive...). Having worked every summer since I was 17 (20 now) as a QA intern, dev has been something I've been itching to drown in.

In a desperate attempt to pull this off I polished my linkedIn up to a shine an applied to everything that so much as mentioned the words summer and intern. Following this....I waited....and waited....and got denied...and told, most fabulously, to come back in two years when I have an actual college degree on the horizon. This as you might imagine, is just a tad disheartening! But absolutely nothing that every other student doesn't have to compete with over their degree so.

The rain

However, months after beginning this crusade. A response. Two in fact! Lets call them company A and company B, the preparations began in ernest. I studied cracking the code interview, I did hackerRank challenges until everything looked like a linkedList and HashMaps became my world. I did however...also happen to schedule the technical interview with company A for the next week, utterly a mistake mind you, but I was excited and prayed that if I looked eager it would work in my advantage. I was....so horribly wrong, as company B had yet to let me know when they wanted to give me a call....

The flood

So as the days ticked by and I forgot about the second interview. I worked away until, to my horror, a wonderfully friendly email landed in my inbox. The second interview...was scheduled for exactly one hour following the first.

You can imagine the panic setting in

Thankfully it was not technical, but behavioral! A light in the darkness! Less prep more...selling oneself? I supposed? Still, panic was at an all time high and that panic I fear absolutely showed to company A, while with company B, I managed to be so burnt out of stress that the whole wonderful thing flowed neatly from one topic to the next. As a first ever technical interview it certainly could have gone better.

Conclusion

As I write this I'm coming down from the high related to these interviews. Both thankfully were offsite, and were conducted over either skype or mobile which at least took the time fear out of it. I don't think I'll every be as scared about a wednesday afternoon as I was today, but you have to make do with what you have. For those of you staring down the barrel of a loaded interview, I sincerely hope you escape my bad luck.

P.S I have to thank @emmawedekind for her tutorials and tips, because I wouldnt have survived today otherwise

Article No Longer Available

Is E-voting ever a good idea?

Matthew Henry — Sun, 18 Nov 2018 00:42:19 +0000

TLDR; PC or Paper?

As a student I'm constantly exposed to the political microcosm that is the students union and beyond. Seeing this and the comparisons between the wider world I often wonder as a developing (badum bum ching) developer what either impact we can have and what impact we should have on the politics around us.

Now that E-voting is being introduced, and poorly so in many cases, I have to ask, especially to more experiences members of the community. Do you think its a good idea? Do you have any faith in it's implementation?

Or is it all just a stack of cards waiting to fall down.

What Skills do you wish you learned earlier

Matthew Henry — Fri, 09 Nov 2018 18:57:18 +0000

TLDR; Scribble first code later.

Paddle before you dive

I think that as a novice programmer I, and a lot of others have made the same consistent sets of mistakes. Saying that, the most consistently painful of mine has been an utter lack of planning.

I wish that I had learned earlier that the simple act of taking out a pen and paper to just roughly sketch out an implementation or idea would make my life 1000 times easier.

It's all too easy to get overexcited about an idea or a quick fix for an assignment and dive headfirst in to suddenly crack hard against a brick wall. Something that would have been fixed so quickly by taking 10 minutes to hash out the idea, maybe even come up with some actual edge cases. It almost goes without saying that more than half of the act of programming is about solving the problem, but its easy to get carried away and try to solve that problem on the fly.

Slowing down

The act of simply sketching a couple of ideas or hashing out some abstract attributes forces you to think about the problem in ways that are certain to save hours of time and effort down the road.

Pushing it a little further and asking for the opinion of a peer, especially if they're of a similar level of proficiency as you only adds to this.

You're not asking for a solution from them, just an extra pair of eyes to see what you miss.

The volume of trouble I'd have saved by learning this is immense, but that's all part of the process! So go and get a pencil and some paper, scribble out you're grand plans, and hopefully, avoid the pitfalls.

Your thoughts

What skills do you wish you learned earlier in your career, either as a programmer, a student or otherwise? What heartache might it have saved you in the long run?