signal-cli-rest-api
signal-cli-rest-api copied to clipboard
bbernhard
Introduce a reusable logical invocation layer
Introduce a reusable logical invocation layer
Hi there,
I like the effort that went into wrapping the Java CLI into a well working REST service. The decent error handling an the used domain model are definitely a big chunk of work. My question is: would you guys consider separating the CLI invocation parts from the single api.go file into a separate reusable logical layer? So effectively decouple the transformation of REST inputs and the gin context from the actual invocation via plain domain model entities.
If configured correctly this would provide the possibility to invoke the Signal CLI directly within other Golang components reusing the available error handling and domain objects and bypassing the HTTP / REST mapping, error handling, etc.
Let me know whether this sounds like gibberish or if you would consider it a topic worth talking about.
Cheers and keep up the great work!
I can agree with @jenpet. This would bring the signal-cli to a new level. In the moment, I forked the repository and made an gRPC-based API of the signal-cli. With just a "signal"-go-module, Those projects could be realized very easily.
That would definitely be nice and I think it shouldn't be too much work either.
The only thing I am not sure about, is whether its better to create a separate github repo for the library or if it should be part of this repository here. I am leaning towards the former, as I find it a bit strange to have a generic library in a "REST API wrapper" repository. But I think that's something that we could also decide later.
I think the best way to start is probably to create some new go files and separate the CLI invocation parts from go-gin. (so basically what @jenpet suggested). Once that is done we can decide where to put it.
If someone wants to start working on it, please feel free to do so - any help is highly appreciated! If not, I could have a look at it either this weekend or the next one.
I'm glad that I hit a hit a nerve with that suggestion. As @bbernhard suggested I'd put it in a separate layer within this repository first and migrate it somewhere else subsequently if it works out in other services / repos like your @Dattito.
I can give it a try if you guys are open for it. But it'll definitely take me some time since I'm quite busy the upcoming days. If you tackle it first @bbernhard just drop a quick note.
You could think about whether to aggregate all of the go-signal efforts in a separate org (gognal ^^ ) containing a core, rest and grpc repo. But that's a completely different story.
Thanks for the feedback!
fyi: I am currently working on this (still WIP though). In case you want to have a look, the changes are currently on the jsonrpc branch.