Support for RPC calls

[emilianozublena]

Hi everyone! Are there any plans to have this plugin also able to make RPC calls? As our current PoC is being develop, we're looking into a way for having a REST API exposed to clients (eg: web app or third party devs) while having all our backends behind rabbitmq. In order to do so, and because the plugin right now only supports fire n forget, we're looking into enabling RPC inside this plugin so we can leverage all Rabbit's flavors (such as autoscaling and so on) instead of plugin directly our services to kraken. Hope this makes sense, i'll start working on a fork of this repo, but wanted to first check out if you guys had any plans for this.

Thanks again!

[emilianozublena]

Hi @kpacha any ideas on this? as i said, i'm currently working on something to do this, but would be awesome to have some degree of official support for this as well...

Thanks a lot!

[kpacha]

In all the times I've been thinking about what features should a pure api gateway offer, I never thought adding RPC over amqp. This is a comment and not a down vote for the feature proposal. The required deps are already included, so if the implementation makes sense, I'm ok merging it to the main branch.

In my opinion, the implementation will raise some questions regarding the semantics (at least one, at most one) and the queue management (e.g.: what happens when the client is disconnected when the response is available at the queue?). What are your ideas on that?

[emilianozublena]

Thanks for your answer @kpacha! It raises a lot of questions for sure, we're currently developing a PoC so this is not the only approach we're using -basically we want to compare kraken -> gprc -> service, kraken -> amqp-rpc -> service, kraken -> rest-json -> service, and the same transport layers with Kong as our gateway- benchmark everything and make a decision based on performance, effort, scalability, and so on.

Regarding your example, we're assuming it's the same as if the client is disconnected in a regular rpc/rest-json comm, in order to avoid population of not consumed msgs and queues we're going to set these ones as not durable/autodelete so they get deleted if no one consumes them.

Background reasoning is to try to avoid having different types of communication if possible (eg: services having both REST APIs and message-driven APIs), but maybe it ends up being a no-go, we're still unsure tbh.

[emilianozublena]

@kpacha i've been hitting an issue with krakend and i'm not sure how to move forward.

2021/02/01 11:53:05  WARNING: loading plugins: plugin loader found 1 error(s): 
opening plugin 0 (./krakend-amqp-rpc.so): plugin.Open("./krakend-amqp-rpc"): plugin was built with a different version of package errors

My local go bin version is 1.12, same one as required by krakend as far as i can see. and i'm not entirely sure as to which version of "errors" is kraken using (i'm assuming that's the reason for this error)

Thanks for any input!

[kpacha]

there is a small tool for checking the deps and versions for krakend plugins: http://plugin-tools.krakend.io/validate

by the way, go1.12 is too old for building krakend plugins. krakend 1.0.0 was compiled with go1.13.0

[kpacha]

The validator also tells you which go version you should use to compile the plugin depending on your krakend version. http://plugin-tools.krakend.io/versions/v1.2.0

1.11.0, 1.12.0 and 1.15.0 will never work because these versions haven't been used in our compilations

[emilianozublena]

Got it, issue was related to a minor version diff between my go and go version used for krakend.

KrakenD 1.2.0 was built using Go version: 1.15.2, mine was 1.15.5 thus it was throwing all kinds of errors. Now i'm on track (i hope). Thanks for all your help! will keep posted regarding this plugin