Why Use FRHTTP

There are a number of benefits to the functional reactive approach vs the callback or the (req, res, next) approach. This blog post details what we mean by functional reactive in the context of FRHTTP. It's a short read and will help ensure we're using the same vocabulary.

FRHTTP doesn't suffer from callback hell

Callbacks become cumbersome pretty quickly. There are a number of libraries designed to help you with this but none of them address root problems with callbacks. Namely that they're very difficult to debug and callback stacks are by their nature risky to inject into. Contrast this with the FRHTTP approach of figuring out when to call your functions based on when values you need are ready. In the latter scenario, FRHTTP is responsible for hanging your functions together at runtime. If you want to "inject" something, just write another when block and stick it in. Also since FRHTTP functions operate only on their inputs, and declare their outputs, you can immediately see how they will execute.

FRHTTP encourages the use of pure functions

Pure functions are affected only by their inputs. This means that every time you pass inputs, you get exactly the same output. This makes writing tests very easy, it also makes error tracking much easier.

FRHTTP's error reporting makes reproducing problems trivial

If a function in FRHTTP throws an exception, the function and the input that caused the exception are reported. If you followed the rules about pure functions, recreating the error is trivial.