Server as a Function. In Kotlin. _____________

The birth of http4k: What started as a rewrite of a major scientific publisher's website evolved into the world's most testable web framework, now boasting millions of downloads monthly across its 180-module ecosystem. Learn how we built an entire HTTP toolkit from the ground up using pure functions and zero magic to deliver unprecedented testability.

http4k's unique design choices - born from real-world, high-scale demands - make it possible to test every aspect of your system with remarkable ease. By combining functional programming principles with a ruthless focus on testability, we've created a framework that makes building and testing web applications dramatically simpler than traditional approaches.

Throughout this talk, we'll demonstrate how http4k grew from a single project's needs into a comprehensive HTTP ecosystem, powering everything from high-performance APIs to complex web applications. You'll see firsthand how its pure-functional approach and extensive module system let you build exactly what you need, while keeping your applications remarkably simple to test and maintain.

Key focus areas:

- How a single project spawned the world's most testable web framework
- The evolution into a 180-module HTTP ecosystem
- How http4k also reimagines monolithic API client design
- A zero-magic approach to pure functional web development
- Practical demonstration of http4k's super- efficient design

Transcript

1. Server as a Function. In Kotlin. _________________. David Denton GITEX 2024, Dubai
2. Server as a Function. In Kotlin. _________________. David Denton GITEX 2024, Dubai
3. GDE Hello, it’s David! @daviddenton https://monopolis.cloud https://clockwork.ing/
4. What’s the plan? •Let’s talk about publishing! •Why use a functional HTTP model? •Server as a Function: Concepts & Origin •How http4k leverages this model in Kotlin •Expanding the http4k ecosystem
5. Let’s talk about publishing! •Project was a major academic publisher •Rebuild global web content delivery •JVM stack •Trunk-Based Development •CICD <20min lead time
6. • Immutability is safer than mutable • Functional programs are more lightweight • Annotations / Re fl ection / Magic == hard to understand/predict • Testing is much easier, quicker and safer Why use a functional HTTP model?
7. Server as a Function. In Kotlin. ________________
8. Server as a Function. In Kotlin. ________________ So what is it?
9. The original whitepaper • 2013 white paper from Marius Eriksen @ Twitter • De fi ned composing of Services into two types of function: • Service - Represents a system boundary • Filter - aka middleware - Models application agnostic concerns
10. What does that look like? Wire systems together with functional transformation Service* O Service* Y * A Service boundary is either a Server or a Client ReqO RespO Service<ReqO, RespO> Service<ReqY, RespY>
11. What does that look like? Wire systems together with functional transformation Service* O Service* Y * A Service boundary is either a Server or a Client ReqO RespO Service<ReqO, RespO> Service<ReqY, RespY> Add Auth (Filter) ReqY RespY Filter<ReqO, RespO, ReqY, RespY>
12. What does that look like? Wire systems together with functional transformation Service* O Service* Y * A Service boundary is either a Server or a Client ReqO RespO Service<ReqO, RespO> Service<ReqY, RespY> Add Auth (Filter) ReqY RespY Filter<ReqO, RespO, ReqY, RespY> ReqY RespY Audit (Filter) Filter<ReqY, RespY, ReqY, RespY>
13. Moving into reality • Finagle runs the Twitter backend • Scala ecosystem project • Many protocols supported • HTTP layer: Finch
14. Issues with Finagle • Scala not a popular (or easy) choice • Future-based => adds complexity • Protocol agnostic => too generic • Conclusion: We need to go simpler!
15. Server as a Function. In Kotlin. ___________
16. Server as a Function. In Kotlin. ___________ Distilled.
17. an entire HTTP ecosystem
18. The http4k ethos • Simpler is better. • Embrace functional concepts. • Zero re fl ection. Zero magic. • Minimise dependencies => Secure. • Testability & fl ow are king.
19. Refining the model for HTTP Inputs and output are the same at each stage ServiceA ServiceB * An Service is either an HTTP Server or an HTTP Client HTTP HTTP HTTP (Request) -> Response (Request) -> Response
20. Refining the model for HTTP Inputs and output are the same at each stage ServiceA ServiceB * An Service is either an HTTP Server or an HTTP Client HTTP HTTP HTTP (Request) -> Response Add Auth (Filter) HTTP HTTP (Request) -> Response (Request) -> Response
21. Refining the model for HTTP Inputs and output are the same at each stage ServiceA ServiceB * An Service is either an HTTP Server or an HTTP Client HTTP HTTP HTTP (Request) -> Response Add Auth (Filter) HTTP HTTP (Request) -> Response Audit (Filter) HTTP HTTP (Request) -> Response (Request) -> Response
22. Concept: HttpMessage “Request and Response should just be immutable data” ie. they retain equality when compared
23. Concept: Service HttpHandler “It turns an HTTP Request into a Response” ie. it’s just a function! typealias HttpHandler = (Request) -> Response
24. Concept: Filter “It decorates an HttpHandler” ie. it’s just a function! Filter: (HttpHandler) -> HttpHandler
25. Don’t build apps - compose them! Filter.then(next: Filter) : Filter Filter.then(next: HttpHandler) : HttpHandler
26. Concept: Router “It matches an HTTP Request against a HttpHandler” ie. it’s just a function! Router: (Request) -> HttpHandler? Thus we can compose routes together
27. Serving HTTP “Attaching an HttpHandler to a runtime => Server” ie. We have split the application from the runtime
28. Serving HTTP “Attaching an HttpHandler to a runtime => Server” ie. We have split the application from the runtime
29. Serving HTTP “Attaching an HttpHandler to a runtime => Server” ie. We have split the application from the runtime x12 server backends
30. Consuming HTTP “We can reuse the uniform HttpHandler concept” typealias HttpHandler = (Request) -> Response
31. Consuming HTTP “We can reuse the uniform HttpHandler concept” typealias HttpHandler = (Request) -> Response
32. Consuming HTTP “We can reuse the uniform HttpHandler concept” typealias HttpHandler = (Request) -> Response x8 HTTP clients
33. • Super simple • We are only testing functions • All messages are data • We can reuse the same test across the pyramid Extreme Testability
34. • Super simple • We are only testing functions • All messages are data • We can reuse the same test across the pyramid Extreme Testability
35. Unify your stack! “Building stacks by composing fi lters and HttpHandlers
36. Bus Abstraction Remote Client The Layer Cake Route Route Route Route
37. Bus Abstraction Remote Client The Layer Cake Application Business Abstraction Business Abstraction Route Route Route Route
38. Bus Abstraction Remote Client The Layer Cake Application Stack Logging Metrics Remote Clients Application Business Abstraction Business Abstraction Route Route Route Route
39. Bus Abstraction Remote Client Launcher Load Environment Con fi guration Launch Embedded Runtime The Layer Cake Application Stack Logging Metrics Remote Clients Application Business Abstraction Business Abstraction Route Route Route Route
40. Let’s build a Proxy in 1 LOC! • We can plug a client directly into a server as they are the same interface • The rest is just decoration (using only function composition)
41. Code your API documentation! • http4k can auto document APIs with it’s OpenAPI module • This unlocks lots of tooling • Always up-to-date
42. Server as a Function. In Kotlin. _______________________
43. Server as a Function. In Kotlin. _______________________ Without the Server?
44. Multi-runtime applications No changes!
45. In-memory • By default, http4k apps run entirely in- memory • Tests and testing environments are in a single JVM and run instantly • Compose many apps together!
46. In-memory • By default, http4k apps run entirely in- memory • Tests and testing environments are in a single JVM and run instantly • Compose many apps together!
47. In-memory • By default, http4k apps run entirely in- memory • Tests and testing environments are in a single JVM and run instantly • Compose many apps together! Test / JVM Environment Con fi guration
48. Serverless • Performance dependent on lightweight binaries • For us, Serverless is just another runtime x6 serverless platforms
49. Native ❤ • Java can now statically link to native binaries • Tiny footprint + simple design => Perfect match! • http4k compiles to Native with zero changes
50. Performance • Tech-wide benchmarking • Covers HTML, JSON, DB, Caching • Over 300 entries in 40 languages • http4k maintains high rank in Kotlin • … with no performance hacks
51. • 83 integrations and counting • Best-in-class Testing support • ~1.7m downloads per month (+ rising!) • Weekly releases • Kotlin Foundation Supported
52. That’s all very good, but… what about talking to other systems?
53. Client as a Function. In Kotlin. ______________
54. Client as a Function. In Kotlin. ______________ Reimagined.
55. /endpoint2 /endpoint1 /endpoint3 Business logic API Client API Client Data access /endpoint4 API Client The other side of the world
56. /endpoint2 /endpoint1 /endpoint3 Business logic API Client API Client Data access /endpoint4 API Client The other side of the world We talk a lot about these….
57. /endpoint2 /endpoint1 /endpoint3 Business logic API Client API Client Data access /endpoint4 API Client The other side of the world … but never about these! We talk a lot about these….
58. The problem with client SDKs • DevEx for API clients is inconsistent • SDKs not testable, no observability • Limited (if any) control of underlying clients • Heavyweight binaries => bad for Native, Serverless
59. … so we built http4k Connect • Featherweight Kotlin API Clients • Based on single functional concept • Zero re fl ection ❤ serverless* & graal • Consistent DevEx • Testability, observability, extendability *https://bit.ly/kotlin-serverless
60. • 35 integrations and counting • Integrate with cloud & AI services • In-memory fakes for testing • Highly extensible https://connect.http4k.org
61. Everything as a Function. In Kotlin. _____________
62. Everything as a Function. In Kotlin. _____________ Demo time
63. Challenge: build a Dropbox clone • Must have minimal footprint • Authenticated UI with OAuth • List, Upload, View fi les • API to list fi les, protected by API key • Leverage OpenAPI • Run either 100% locally or in-Cloud
64. What you’re about to see…
65. What you’re about to see… … because I’ve done live demos before!
66. What you’re about to see… Log in with GitHub OAuth … because I’ve done live demos before!
67. What you’re about to see… Log in with GitHub OAuth … because I’ve done live demos before! Upload fi les to http4kbox
68. What you’re about to see… Log in with GitHub OAuth … because I’ve done live demos before! Upload fi les to http4kbox List and delete a fi le
69. What you’re about to see… Log in with GitHub OAuth … because I’ve done live demos before! Upload fi les to http4kbox List and delete a fi le Visit OpenAPI docs
70. What you’re about to see… Log in with GitHub OAuth … because I’ve done live demos before! Upload fi les to http4kbox List and delete a fi le Visit OpenAPI docs Log in with API Key
71. What you’re about to see… Log in with GitHub OAuth … because I’ve done live demos before! Upload fi les to http4kbox List and delete a fi le Visit OpenAPI docs Log in with API Key List fi les using API
74. Architecture: http4kbox + } +100 lines of Kotlin = 11mb JAR
75. • Tools for leveraging the ecosystem • Available as web / CLI / IntelliJ plugin • Soon: LLM model trained on http4k https://toolbox.http4k.org
76. What have we learned? •The Server as a Function model is incredibly powerful •Functional concepts compose in unexpected ways •Simplicity does not mean bad performance •Testability and Observability should be baked in
77. Thank you! _____________? David Denton Architect | Head of Engineering | Advisory | Training https://clockwork.ing/ https://http4k.org