[sa46]

I worked with a framework like that inside Google in Java. Was okay. You’d write a bunch of methods and the framework would wire up annotated method parameters and return types. The main benefit was improved tail latency since the framework would traverse the graph and run the methods with optimal concurrency.

Same downsides as runtime dependency injection frameworks like Guice—the framework would explode if it couldn’t connect the graph.

Some other upsides: you could decorate methods with all sorts of distributed goodness like retries and hedging. The approach also enable reusable methods that you snap into your server.

[aleksiy123]

Producer graphs?

Maybe just me but I find them completely unreadable and painful.

I don't really think there anything inherently better about having the framework connect things through inputs and outputs or developer explicitly specifying the connections through function calls.

In both cases the executor can decide how to execute the graph.

[bbsimonbb]

Are you talking about this? https://patents.google.com/patent/US7865872B2/en

[aleksiy123]

No, unfortunately the framework itself is not public.

[bbsimonbb]

That sounds very cool indeed.