
RestCommander: Fast Parallel Async HTTP Client as a Service - nikolay
https://github.com/eBay/restcommander
======
lkrubner
This looks impressive but I am a little disappointed about the assumption of
REST. We have recently turned away from REST and are moving toward a
React/GraphQL architecture. We have been studying the possibility of something
like Aleph, or even Apache Storm, combined with "bolts" or processes running
our GraphQL server, as a way of running a GraphyQL at scale (Node is known for
suffering at scale from its lack of backpressure). I would love to see
something like RestCommander for GraphQL. The Play framework certainly seems
like it could help in that area, though I personally have not worked with
Play, so I can't have a strong opinion about it. A devops person might insist
that something like Supervisord is enough to keep things going at scale, but
of course, monitoring 1,000 servers is difficult, and even Supervisord can
die. I appreciate the effort to come up with something that offers us another
way to support running multiple instances of our servers, and perhaps bringing
the monitoring closer to the app.

~~~
ssmoot
I don't have much practical experience with Storm, but I was pretty interested
in it a few years back.

After working with Akka more and more the past year, I have to wonder what
would inspire someone to choose Storm over it though. Akka scales from
millions of messages all the way don't to "I need an end-point for a web-
socket", or a single Actor for unique id generation.

It's really an amazing technology. A bit of boiler-plate, but certainly no
more than something like Storm and you get to a place where it's 30 seconds of
setup before you start implementing your flows.

It's like that old idea that eventually you'd be able to take a Visio diagram,
and just translate it to code. It's flow-chart logic diagrams made manifest.
Completely unlike anything else I've ever experienced. Started with Imperative
programming with BASIC, moved on to OOP and very primitive rules engines with
c#, DSLs and code-rewriting with S-expressions with Ruby, introduced to
functional programming by Scala. Then I get into Akka and despite working with
the same language it feels like a whole other paradigm with just as
significant a shift and contribution to make as the others.

So wondering across posts on Storm (or more routinely lately, Spark), make me
wonder if anyone else feels the same, or if all of these tools are kind of in
that same category.

Or maybe I'm just overselling Akka. But when you hear a Rubyist reverentially
refer to message-passing and Smalltalk, I'm pretty sure no one I ever
discussed that with ever envisioned anything like Akka. I certainly didn't.
`receiver.send(message)` in Ruby is to message passing as Ruby lambdas are to
functional programming (despite lacking composition, currying, partial
function domains, etc). Or switch statements are to pattern-matching. IOW, not
really at all.

Which was really hard to appreciate as a Rubyist before experiencing it
myself.

Have you considered Akka? Found it lacking somewhere maybe? Any direct
experience with Storm? Do you get the same sort of "previously unknown to me
but now obviously equally fundamental pillar of programming structure" sort of
of vibe?

Just curious.

~~~
merb
Actually setting up a Actor come's with a cost. However akka has a great
streams library now. Which is way cheaper for basic pipelines.

~~~
ssmoot
I'm not sure what you're referring to about cost. Maintenance? Performance?

