Ok the limited use of mock servers was annoying me, so what is the answer these days? That’s right, we vibe-code a solution. Behold Clavin (ha-ha-ha, because postman).
Sure, it only works on localhost but that’s fine for my use case. For other things, use ngrok, or whatever.
This is a special kind of rant, so I’m starting a new tag in addition to it. It’ll be updated next year, I’m sure.
The state of yak shaving in today’s computing world is insane.
Here we go.
It’s 2024, and…
****** processing amazon-cloudwatch-agent ******2024/04/05 20:51:36 E! Please make sure the credentials and region set correctly on your hosts.
#!/bin/bash
inst_id=$(ec2metadata --instance-id)
while :
do
used_megs=$(free --mega | awk 'NR!=1 {print $3}' | head -1)
aws cloudwatch put-metric-data \
--namespace gg \
--metric-name mem4 \
--dimensions InstanceId=${inst_id} \
--unit "Megabytes" \
--value $used_megs
sleep 60
doneI like Postman in general. But some things are annoying, so there…
APIs and Collections and Environments
APIs are great, and equally great is their integration with GitHub, and ability to generate Collections from API definitions and have them be updated when API definition changes. Nice. Except… those Collections cannot be used to create Monitors or Mock servers, you need to create standalone Collections (or copy those you generated from under APIs). But now those don’t integrate with GitHub. There is a fork-and-merge mechanism that kind of takes care of the collaboration, but that those modes are different is annoying. Ditto Environments. What’s up with that?
As someone who offers a REST API, we at Romana project wanted to provide documentation on it via Swagger. But writing out JSON files by hand seemed not just tedious (and thus error-prone), but also likely to result in an outdated documentation down the road.
Why not automate this process, sort of like godoc? Here I walk you through an initial attempt at doing that — a Go program that takes as input Go-based REST service code and outputs Swagger YAML files.
It is not yet available as a separate project, so I will go over the code in the main Romana code base.
NOTE: This approach assumes the services are based on the Romana-specific REST layer on top of Negroni and Gorilla MUX. But a similar approach can be taken without Romana-specific code — or Romana approach can be adopted.
The entry point of the doc tool for generating the Swagger docs is in doc.go.
The first step is to run Analyzer on the entire repository. The Analyzer:
The next step is to run the Swaggerer — the Swagger YAML generator.
At the moment we have 6 REST services to generate documentation for. For now, I’ll explicitly name them in main code. This is the only hardcoded/non-introspectable part here.
From here we, for each service, Initialize Swaggerer and call its Process() method, which will, in turn, call the main workhorse, the getPaths() method, which will, for each Route:
This is pretty much it.
As an example, here is Swagger YAML for the Policy service.
The combination of Negroni and Gorilla MUX is a useful combination for buildng REST applications. However, there are some features I felt were necessary to be built on top. This has not been made into a separate project, and in fact I doubt that it needs to — the world doesn’t need more “frameworks” to add to the paralysis of choice. I think it would be better, instead, to go over some of these that may be of use, so I’ll do that here and in further blog entries.
This was borne out of some real cases at Romana; here I’ll show examples of some of these features in a real project.
At the core of it all is a Service interface, representing a REST service. It has an Initialize() method that would initialize a Negroni, add some middleware (we will see below) and set up Gorilla Mux Router using its Routes. Overall this part is a very thin layer on top of Negroni and Gorilla and can be easily seen from the above-linked source files. But there are some nice little features worth explaining in detail below.
In the below, we assume that the notions of Gorilla’s Routes and Handlers are understood.
While we have to define our route handlers as taking interface{} as input, nonetheless, it would be nice if the handler received a struct it expects so it can cast it to the proper one and proceed, instead of each handler parsing the provided JSON payload.
To that end, we introduce a MakeMessage field in Route. As its godoc says, “This should return a POINTER to an instance which this route expects as an input”, but let’s illustrate what it means if it is confusing.
Let us consider a route handling an IP allocation request. The input it needs is an IPAMAddressRequest, and so we set its MakeMessage field to a function returning that, as in
func() interface{} {
return &api.IPAMAddressRequest{}
}
Looks convoluted, right? But here is what happens:
The handlers of routes are not called directly, they are wrapped by wrapHandler() method, which will:
Voila!
Sometimes we prototype features outside of the Go-bases server — as we may be calling out to various CLI utilities (iptables, kubectl, etc), it is easier to first ensure the calls work as CLI or shell scripts, and iterate there. But for some demonstration/QA purposes we still would like to have this functionality available via a REST call to the main Romana service. Enter the hooks functionality.
A Route can specify a Hook field, which is a structure that defines:
Hooks are specified in the Romana config, and are set up during service initialization (this is in keeping with the idea that no Go code needs to be modified for this prototyping exercise).
Then during a request, they are executed by the wrapHandler() method (it has been described above).
That’s it! And it allows for doing some work outside the server to et it right, and only then bother about adding the functionality into the server’s code.
If this doesn’t seem like that much, wait for further installments. There are several more useful features to come. This just sets the stage.
DEBEDb 