Hi all I m currently working through exploring the testing h

Question

Hi all I m currently working through exploring the testing hyperpyramid and do have a question `ShopApi` gets passed in one `httpHandler` which is being used via `outgoingHttp` for two different targets The `Warehouse` and `SESNotifications` In `LocalShopApiTests` `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 slightly smiling face Thanks in advance

s4nchez · Answer

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

s4nchez · Answer

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 · Answer

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 · Answer

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 · Answer

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 slightly smiling face

Philipp Mayer · Answer

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 · Answer

gt 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 · Answer

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 · Answer

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 · Answer

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 gt 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 · Answer

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 · Answer

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

dave · Answer

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 joy

Philipp Mayer · Answer

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 · Answer

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 slightly smiling face

Philipp Mayer · Answer

Awesome that s what I call great engineering culture Thanks for the in depth explanations