How Do You Handle Async APIs and Callback Hell?
While asynchronous APIs can bring advantages, they certainly complicate programming by forcing developers to manually string together sequential operations using callbacks, causing a phenomenon called "Callback Hell".
InfoQ wants to know: how do you handle asynchronous APIs? How do you stay out of Callback Hell or how do you manage it?
Language features and related
These are solutions that are either straight up language features or are supported by language features (eg. macros, etc).
- C# Async/Await
- Scala Async/Await
- Clojure's core.async
- F# Async Workflows
- Stratified JS
- Ocaml lightweight threading (Lwt, Async and others)
- Haskell lightweight threads
- Ruby Fibers
- Other language with lightweight threads
Extensions of the language runtime or bytecode
- Reactive Extensions (Rx)
- Promises or Futures
Promises (and their namesakes) have been adopted by many (standard) libraries and make it easier to chain operations.
- Embedded DSL-style libraries
- State machines
Using libraries like ignite.js, Ragel, etc.
- Just write callbacks!
Is "Callback Hell" just bad developers complaining about their tools? Do you just grit your teeth and nest your callbacks rather spend weeks researching alternative solutions?
- Synchronous APIs
Do you avoid asynchronous APIs at all costs?
Note: if we missed your favorite language, library or solution, please tell us about it in the comments.
What other language with lightweight threads?
Law of Demeter
It's a stench of a Law of Demeter Violation in progress.
The solution is to Tell, don't Ask.
We use kontraktor :-)
check out this
Async API in Java
Its CallbackEvictor module works creating a proxy over invoked service, it pauses the application flow while is waiting the async reply and continue the execution when internal callback is executed with the expected result.
Surprised that "continuations" was not one of the options.