nats

Table of Contents Setup Builder Watcher WatchFuncs Example type Main Demo Example Repo One pattern I’ve used previously was setting up real time configs for services using NATS KV. A KV watcher would monitor the config value(s) and then in real time update values in a service. I guess you could think of this as service level feature flags. I had thought about writing a small Go package for this but it’s not enough to warrant a package so I figured I’d just write a small post about it....

My disdain for GitHub actions seems to increase daily. I just want simple CI. I don’t want to find some random persons action and have to pin to a version of it. I don’t want to learn their specific options. I don’t want to have to make a change, push it to test it, and find out something doesn’t work, over and over again. Yes I’ve tried act but it doesn’t behave exactly the same and sometimes things get wonky....

NATS and SSE Recently Synaida has released their preview of their HTTP Gateway. This allows for clients to use NATS who otherwise wouldn’t have the ability. This is a cool idea and I figured I’d take a stab at building a small PoC that would offer similar capabilities. Right now, Synadia’s HTTP Gateway supports KV and pub/sub. I wanted to take this a step further and leverage Jetstream under the hood....

Micro Handlers The Synadia team has a nice package for creating micro services. In the Go client, this is the micro package. The beautiful thing about this setup is it follows the same pattern as the std library HTTP handlers. The micro package has an interface defined as Handler(micro.Request). Functions can be wrapped with micro.HandlerFunc() just like you can wrap an HTTP handler with http.HandlerFunc(). This allows for the same midleware layouts as you normally have in HTTP servers....

I’ve been using gqlgen at work for a few services and while I don’t normally like code generators, it does a decent job of staying out of the way. One thing I had hoped for was the ability to use the resolvers it generates with NATS instead of needing HTTP. I found an issue referencing this, and the gqlgen team mentioned they didn’t want to specifically support NATS because the resolvers were agnostic....

Overview Piggy Bank was born from a desire to easily store accessible secrets anywhere and not needing to expose HTTP ports for things like Vault. This project is no where near as robust as Vault (hence the name Piggy Bank) but it is desirable to be able to store secrets in the NATS KV store and have secrets be accessible to services using the bus. Authentication Authentication and authorization is done by using normal NATS auth....