Recently, I’ve been looking at the principles of a middleware layer and especially on how a RESTFULL API could glue different IT services together.
I am reading more and more about the “API economy”
I’ve also seen this excellent video made by Mat Ryer about how to code an API in GO and why go would be the perfect language to code such a portal.
The problem I’m facing is that in the organization I’m working for, the developments are heterogeneous and therefore you can find ruby teams as well as python teams and myself as a go team (That will change in the future anyway) The key point is that I would like my middleware to serve as an entry point to the services provided by the department.
We (as an “ops” team) would then be able to present the interface via, for example, a swagger like interface, take care of the API and do whatever RPC to any submodule.
An example: a IAAS like interface
Let’s consider a node compute lifecycle.
What I’d like to be able to do is:
- to create a node
- to update a node (maybe)
- to delete a node
- to get the status of the node
The backend is whatever service, able to create a node, such as openstack, vmware vcac, juju, … Thoses services usually provide RESTfull API.
I’ve seen in my experience, that usually, the API are given with a library in a so called “modern language”. This aim to simplify the development of the clients. Sometimes this library may also be developed by an internal team that will take care of the maintenance.
In my example, we will consider that the library is a simple gem file developed in ruby. Therefore, our service will be a simple server that will get RPC calls, call the good method in the gemfile and that will, in fine transfer it to the backend.
The RestFull API.
I will use the example described here as a basis for this post. Of course there are many other examples and excellent go packages that may be used, but according to Mat Ryer, I will stick to the idiomatic approach.
The glue: MSGPACK-RPC
There are several methods for RPC-ing between different languages. Ages ago, there was xml-rpc; then there has been json-rpc; I will use msgpack-rpc which is a binary, json base codec. The communication between the Go client and the ruby server will be done over TCP via HTTP for example.
Later on, outside of the scope of this post, I may use ZMQ (as I have already blogged about 0MQ communication between those languages).
The implementation of the Client (the go part)
I will describe here the node creation via a POST method, and consider that the other methods could be implemented in a similar way.
The signature of the node creation
Here is the expected signature for creating a compute element:
The corresponding GO structure is:
The Middleware is using the gorilla mux package. According the description, I will add an entry in the routes array (into the routes.go file):
Note : I am using a prefix
/v1 for my API, for exploitation purpose.
I will then create the corresponding handler in the file with this signature
That’s in this function that will be implemented RPC (client part). To keep it simple at the beginning, I will instantiate a TCP connection on every call. Don’t throw things at me, that will be changed later following the advice of Mat Ryer.
The implementation of the handler
The effective remote procedure call
To use msgpack I need to import the go implementation
This library will take care of the encoding/decoding of the messages.
Let’s dial the RPC server and call the
NodeCreate method with, as argument, the information we had from the JSON input
The RPC server (the ruby part)
This part is written in ruby, and will take care of the effective node creation.
At first, we should install the GEM file with the command
gem install msgpack-rpc.
let’s test it
Launch the RPC server:
Then launch the API rest server
go run *go
Then perform a POST request
It should write something like this:
2015/11/10 13:56:51 POST /v1/nodes NodeCreate 2.520673ms ok
And something like this in the output of the ruby code:
Creating the node with parameters: linux S 20 1 dev my_description
That’s all folks! What’s left:
- To implement the other methods to be “CRUD” compliant
- To implement an authentication and accreditation mechanism (JWT, Oauth, ?)
- To change the implementation of the RPC client to use a pool instead of a single connection
- To implement the swagger interface and documentation of the API
- Whatever fancy stuff you may want from a production ready interface.
You can find all the codes in the github repository here in the branch