Decoupling micro-services using Message-based RPC
So I was mucking around — creating a quick PoC with Tyk. I wanted to extend Tyk API Gateway so that rather than calling a typical API upstream, I would intercept the request, send to a gRPC server written in GoLang, which defers the work to an off-process messaging queue based worker. Typically — messaging queues are asynchronous — but in order to achieve a synchronous call (as far as client is concerned), we have to do a little RPC messaging queue magic. Read on if this sounds fun or just jump to the code!
https://github.com/asoorm/tyk-rmq-middleware
What are we tinkering with?
API Management & API Gateway — Tyk is an Open Source API Gateway. The fact that I can extend Tyk by writing my own custom functionality in any language which supports gRPC is seriously powerful. https://tyk.io
RabbitMQ — Many organisations use the awesome RabbitMQ https://www.rabbitmq.com/ an open-source message broker.
gRPC and protocol buffers — https://grpc.io/ In gRPC a client application can directly call methods on a server application on a different machine as if it was a local object. Protocol Buffers are Google’s language-neutral mechanism for serialising structured data.
Json Schema Validation — Tyk can validate your requests against a json schema. http://json-schema.org/
GoLang — Because it’s awesome and has a Gopher as it’s mascot. https://golang.org/
Docker & Docker-Compose — No developer toolkit is complete without docker! https://www.docker.com/
What are we doing?
First, we need to start all our services. We can do this easily with the following command `docker-compose up -d` This will start RabbitMQ, a Worker node & a Tyk gRPC middleware server.
You can visit the rabbit management console by visiting the following url in your browser `http://localhost:15672`, and using the super secure username & password guest:guest combination.
You will see that a rpc_queue has been created with a single consumer. The consumer of this queue is actually our worker service.
The beauty about messaging queues, is that if you need more performance, simply start more workers. No need to faff around with Load Balancers & Service Discovery et al.
Our worker receives messages on the `rpc_queue`, and does something with the message, and replies to the reply_to queue with appropriate correlation_id.
We have another service, which is the `grpc-middleware` service. This is a simple gRPC server which receives messages from Tyk. When a `MyRabbitHook` is received, it reads the message body, creates a temporary queue and publishes the message to the `rpc_queue` and listens on the temporary queue for the response. Once the response has been received, it returns the response via gRPC to Tyk — which in-turn responds with the appropriate message to the client.
Once all is in place, we simply import our API definition, provided in the repo to our Tyk installation. We also need to make sure that the Tyk gateway has been started with grpc enabled alongside the location to the grpc server. Otherwise, it simply won’t work.
Testing the Json Schema Validator:
$ curl -X POST http://localhost:8080/httpbin/post -d '{"firstName": "Ahmet", "lastName": "Soormally"}'
{
"error": "lastName: lastName is required"
}Testing our gRPC Middleware which has deferred our request to some other process via RabbitMQ
$ curl -X POST http://localhost:8080/httpbin/post -d '{"firstName": "Ahmet", "lastName": "Soormally", "age": 36}'{"sentence":"Ahmet Soormally is 36 year's old"}
Caveat
This is a quick n dirty PoC that I put together in about an hour, maybe 2 if i’m being honest.
I know of several quirks already — but am leaving them as easter eggs for you to find. If you see any issues — it’s open-source — attempt to fix, or get in touch if you need help.