Hi all, I’m currently working through exploring th...

# http4k

[Philipp Mayer]

Hi all, I’m currently working through exploring the testing hyperpyramid and do have a question:
ShopApi (Github) gets passed in one httpHandler, which is being used (via outgoingHttp) for two different targets: The Warehouse and SESNotifications.
In LocalShopApiTests (Github), FakeWarehouse() is being passed in, which then ends up also being used for SESNotifications.
Shouldn’t there be two parameters, one that gets a FakeWarehouse and one that gets a FakeSES?
Why is that/what am I missing here? 🙂
Thanks in advance!

[s4nchez]

Yes, to keep adapters clearly separated I tend to recommend going with one handlers per dependency.

[s4nchez]

In that codebase it doesn’t make much difference because in the “end to end” tests we have an environment that can do the routing to the correct system.

[s4nchez]

Also, we didn’t want to complicate the example even further, but usually the “core” of the hexagon should ideally receive clients defined at domain level too, not http handlers directly.

[dave]

Well spotted @Philipp Mayer!

I think there is a bit of a confusion here. The Shop itself will definitely take a single dependency per port - so one for the Email client and one for the Warehouse client. However, I actually support using a single HTTP handler to the ShopAPI (which takes the HTTP "adapter")... and then use the reverse proxy pattern to split the traffic. This means that you only need one HTTP client (or you can also use a reverserproxy when injecting them to direct the traffic to a different HTTP client based on the URL.)

[dave]

The reason that the FakeWarehouse is injected in is because there actually isn't a service level test that exercises the email client in that repo. We created the repo especially for the presentation, so it doesn't contain the amount of testing that we would generally put in covering all functionalities.

We also wanted to keep the codes in the slides as simple as possible - they were complicated enough and the flow of the slides didn't really warrant putting in the FakeSES at that point in the deck! 🙂

[Philipp Mayer]

Thanks for the in-depth explanation you two!
I already thought that it's because of keeping things simple.
I'm curious though: how do you do it at work? I'm building a real world example and I'm curious how my entry point into the module should look like.

Let's say you have a service that calls two other services: do you take 2 URIs and 2 http handlers? Or do you have specific classes that are already wired that you pass in (hexagonal arch aside, I'm aware that this is abstracted away then :) )

[Philipp Mayer]

I actually support using a single HTTP handler to the ShopAPI (which takes the HTTP "adapter")... and then use the reverse proxy pattern to split the traffic. This means that you only need one HTTP client (or you can also use a reverserproxy when injecting them to direct the traffic to a different HTTP client based on the URL.)

Interesting stuff! Is this a common pattern in your services? Passing in one http handler that's actually a reverse proxy which then translates two X services?

[Philipp Mayer]

Sorry for all the questions, but I'm still wrapping my head around it as I didn't have the chance to work on a more complex project with http4k yet.

[dave]

That's ok - questions are welcome!


And the answer to your question is yes - you can use a reverseProxy() in client HTTP handlers to fan out from a single HTTP client, depending on the URL.

[dave]

something like this shows it - it means you can use different retries, timeouts or even different client libraries for each.

val http = reverseProxy(
        WAREHOUSE_URL(ENV).authority to JavaHttpClient(),
        "ses" to JavaHttpClient()
    )

You can really go to town on this stuff - and actually hide is all behind a ServiceDiscovery interface - which is basically:

interface ServiceDiscovery = (AppName) -> HttpHandler

- we did have it in the example repo originally but it complicated the slides too much so we pared it back. But it does make the wiring stuff easier to manage TBH (what became the NetworkAccess in the repo)... especially for running different "universes" - such as an InMemoryUniverse and a StagingUniverse and a LocalServerUniverse....

[dave]

As for the URLs, in our example the app always takes an Environment and passes individual URLs down to the individual clients to be used with a SetBaseHostFrom, but in the case of using a ServiceDiscovery, even that is all taken away and you end up just passing the client... so

HttpWarehouse(env[WAREHOUSE_URL], outgoingHttp)

... would become something like:

HttpWarehouse(serviceDiscovery(AppName.Warehouse)

[dave]

(ie all of the envrironmental stuff is hidden from the main app construction logic)

[dave]

The wider scope for all this is our intention of making application identities, profiles and their dependencies be explicitly codified - there are cool implications that doing this statically in code give you, like being able to make it impossible to create an HTTP client for another application which you have not explicitly declared a dependency on... or you can use the dependency matrix to be built into the tooling - to generate dashboards, or builds or anything else you can think of.

But that's all somewhat a tad more than we had time for in 40 minutes plus questions... 😂

[Philipp Mayer]

One last question: Most of this works by staying rather generic when declaring what dependency is needed (e.g. HttpHandler instead of MyHttpBankClientClass) - how do you assure that other teams/devs use it as intended?
For example, you have AppIncomingHttp and AppOutgoingHttp which are both http handlers that could be mixed up.
More of a design debate now, but I’m curious

[dave]

Well the genericness comes into the main application - the hub itself is always typed to the specific Port interface. (Those last 2 we refer to as "Stacks" BTW because they are just a wrapper around a bunch of Filters).

As for mixing them up, we try to build by convention and by leaning on common infrastructure and tests! So as well as a common set of infra building blocks, we have a common set of test cases (interfaces) which are applied to every service as a base-layer.

These test cases will check for common things like HasOpenApi, or EndpointsAreSecured and they can all be mixed into the main test suite - all you need to do is to provide a base test class which supplies the HTTP handler application setup and implements all of the Test interfaces and you get them all for free 🙂

[Philipp Mayer]

Awesome, that’s what I call great engineering culture. Thanks for the in-depth explanations!