4 ms·
Grabbing the data from the exec response is a super clunky way of communicating between two applications, particularly since Go is really good at keeping long-l
by nkozyra 12y ago
Grabbing the data from the exec response is a super clunky way of communicating between two applications, particularly since Go is really good at keeping long-lived TCP connections.
Even without connecting directly (which is just as trivial as reading a response from exec), you should be looking at a formal message passing system. This also allows you to easily distribute these dissonant applications, which is a good idea when you're talking about "utilizing all the CPUs available" and potentially high network usage.
- Zikes 12y agoI think you're talking about a microservice, and I would agree. Go is well suited for that sort of thing.
- nkozyra 12y agoWell it's a microservice as described in the OP, I'm just talking about formalizing a communication method. Reading CLI responses isn't a very smart way to do it. REST APIs aren't really ideal for slow processes, either, which is why my first thought would be something like RabbitMQ or just a simple TCP connection.
- xentronium 12y agoYes, yes and yes! It's not just clunky. Process spawning is super slow for sub-second operations.
- Jweb_Guru 12y agoProcess spawning is barely slower than spawning a thread on Linux.