I've been thinking of building some sort of batter...

# http4k

[Andrew O'Hara]

I've been thinking of building some sort of batteries-included layer on top of http4k for server applications: meant for novice functional developers, or for those accustomed to frameworks. I'm looking for some common pain-points that could be addressed with this layer, like:

• resource-oriented API builder with common index,get,update, etc. operation helpers
◦ originally, I was going to require the use of result4k, but may instead opt for the familiarity of exception-based error handling
• automated path/body lens building and HTTP message inject/extract
• included server and json modules
• helper to inject ENV into resource initializers
• consider jdbc/h2 integration
◦ despite http4k's incredible DynamoDB integration, it might be a bit niche
◦ include orm like exposed/jooq/??
Does anyone have any thoughts or suggestions on the idea?

[leonhardt]

I had a long run in "Spring Boot land," consulting at the company that owned Spring at the time. Then built an unrelated product using spring boot and started a company around that product. Slowly replaced the web components of Spring Boot in that product with http4k. From the perspective of:
1. things that were hard for me adopting http4k, personally
2. things that would have been hard for me to introduce http4k at my clients who were accustomed to "batteries-included frameworks"
here's my suggestions for a potential batteries-included server framework on top of http4k.

• automated path/body lens building and HTTP message inject/extract

This is the biggest opportunity imo. The lens system is elegant and the syntax is tight. However it's a little novel when learning it and in my experience once a convention is set in a codebase working with lenses starts to feel like a chore. When working with a framework like Spring Boot you don't really even need to know that Jackson is probably doing the deserialization/serialization, it just starts working. If you want a url parameter you just add a function parameter with a particular annotation.
https://spring.io/guides/tutorials/rest/#_http_is_the_platform

• resource-oriented API builder with common index,get,update, etc. operation helpers

◦ originally, I was going to require the use of result4k, but may instead opt for the familiarity of exception-based error handling

FWIW I end up doing this myself in my http4k projects.
If you could find a way to offer alternatives for error handling approaches (e.g. alternate imports or dependencies) I'd be a big fan. Arrow's Either might be a good choice too (given my anecdotal understanding of its popularity).

• consider jdbc/h2 integration

◦ despite http4k's incredible DynamoDB integration, it might be a bit niche
◦ include orm like exposed/jooq/??
I suppose all the big frameworks provide batteries for data access as well, but this is the least exciting one to me. I think the specialization of the http4k framework on HTTP is part of what makes it compelling–and I think that philosophy could make a "batteries-included framework" successful as well. Especially with all the increasingly good options for data access in the ecosystem. Quick shoutout to #squarelibraries's SQLDelight, for example. I feel like the data layer libraries/frameworks/etc out there already pair well with http4k and a framework integrating them for you doesn't add as much benefit for development teams as the other opportunities you've listed.

Overall I think it's an interesting proposition.

[James Richardson]

I do get where you are coming from. However, I wonder if the biggest benefit might come from documentation about that sort of thing, rather than code.

[dave]

I/we have thought about a more generalised platform actually.

I had always envisaged that we'd christen it the "fork stack" - encompassing all of http4k and connect and the forkhandles as a base and adding some primitives for other standard prod infra structure for building and testing apps - probably with jooq/nimbus and any other sensible libs we can find.

There are lots of patterns that we haven't really talked about but keep using, as well as the the "BackOfficeGateway" which is a secured unified support Swagger gateway across all services (and which is secured with SSO). So there would be some value I think in packaging all this stuff into a higher level framework*

*actually a framework because we tell you what to do for a change 😂

[Oliver Eisenbarth]

There are lots of patterns that we haven't really talked about but keep using, as well as the the "BackOfficeGateway" which is a secured unified support Swagger gateway across all services (...)

You mean like the API-Gateway in the "Hyperpyramid"-Example? I was wondering if that was only for presentational purposes or if coding your own Gateway is something you'd do in production / for clients.

[dave]

Nope -although we have put those API gateways into various projects. You can think of the BOG like a single Swagger interface into all of the microservices running in your local cluster. It's protected with SSO (eg. OKTA) and issues it's own JWTs. From that Swagger interface you can interact with the OpenAPI contract endpoints in any of your services - and they are all protected by JWT auth (we usually use something like user groups claims to protect them)

[Oliver Eisenbarth]

That sounds like an API-gateway - or at least some of the functionality vendors offer - to me? I'd be thankful, if you could tell me the difference, as I've never really worked with one (besides putting a lambda behind an AWS gateway). 🙂

[dave]

It's not an API gateway because it doesn't expose an API to anywhere 🙂 - it's a UI.

[Oliver Eisenbarth]

@Andrew O'Hara, I spent 4 yrs in Spring land, too and I would very much welcome some out-of-the box security solution like Spring Security. I've managed to secure a toy example with Keycloak, but tough there are some hints on what to do in the comments, implementing my own CustomOAuthPersistence felt a bit above my head. I'd rather rely on a tested solution for storing and verifying tokens.

[Oliver Eisenbarth]

It's not an API gateway because it doesn't expose an API to anywhere 🙂 - it's a UI.

Well, that makes perfect sense. Thank you! 😅👍

[dave]

Yes - we know that security isn't exactly the simplest thing to implement - there's quite a lot of cover, which is partially why Spring-security is such a pain to configure - generalising over the top is quite hard because of all the different options that you can cover. 😂

The interesting thing about the pattern is that you can implement the BOG once and then automatically get support for accessing all existing and future services through it. It's very handy 🙂

[Oliver Eisenbarth]

Now I'm really curious, how this pattern works. Hopefully @dmcg will do a video about it some day. 😁

[dmcg]

Well as it happens I did work with @dave on a project that used the pattern, but it does kind of presuppose that count(all-of-the-microservices-running-in-your-local-cluster) > 1, and I found as I got older that I’m allergic to microservices.

[dmcg]

At the very least Gilded Rose will have to expand in some pretty radical ways to need to fan out. Maybe if we get a sudden rush of VC funding to capture a market…

[Oliver Eisenbarth]

I found as I got older that I’m allergic to microservices.

Perfect for a Halloween special! "Duncan's Nightmare: #Microservices #BOG #AngryGoblin" 😉