http4js

Release notes

View full release notes

Table of Contents

• Overview
• Handlers and Filters
• Request and Response API
• URI API
• Routing API
• In Memory Testing
• End to End Testing
• Approval testing with fakes
• Zipkin tracing
• Https Server
• Proxy
• Use in Javascript
• Example App

Intro

http4js is a thin layer around node http. Within this layer we can happily unit test our routing logic and easily spin up any function (Req) => Promise<Res> as a server.

Basic Server

We can route a path to a handler and start it as a server:

routes("GET", "/path", async (req) => ResOf(200))
    .asServer()
    .start();

Then we can make a call to this endpoint

HttpClient(new Request("GET", "http://localhost:3000/path"))
    .then(response => console.log(response));
     
/*
Response {
  headers: 
   { date: 'Sun, 25 Mar 2018 09:24:43 GMT',
     connection: 'close',
     'transfer-encoding': 'chunked' },
  body: '',
  status: 200 }
*/

What’s the big idea?

• Having our routing and logic separate from our server and http layer means that we can unit test them away from http so now we do not have to write end to end tests to test our routing.

• The only added benefit of end to end tests now is to test the interaction with the http layer. Testing the http layer is very useful for certain situations, like making sure that certain headers are respected by node’s http layer, or knowing that a certain query string is valid at the http layer, but to test our app and its logic, we no longer need to have slow and painful end to end tests.

• Req and Res are immutable, so you cannot pass a mutable “context” around your code base and mutate it here and there. If you want to jimmy around with the incoming Req then you build a new one, luckily every method on Req returns a new Req, but if you want functions to change your Req it obviously has to explicitly return it as Req is immutable. The same goes for Res.

Next: Handlers and Filters