Why you should be using OpenAPI right now?

Why you should be using OpenAPI right now?

Why you should be using OpenAPI right now?

In Karumi, we are always looking for technologies and tools that help us and help our clients to produce, evolve, and maintain their products with the highest quality and robustness in mind. Most of the time, we have to develop some mobile clients that will consume an already established backend API; or develop both the backend services and the clients using them.

One tool that has been hanging in our belt for the last couple of years is OpenAPI, previously known as Swagger and we are more than pleased with it, so now, it’s my turn to convince you about why you should be using it if you work at any side of an API.

This first blog post is the beginning of a series that will guide you in defining, offering, and consuming an API built from scratch.

What’s OpenAPI?

OpenAPI is a specification that defines a standard that can be used to describe RESTful APIs in an agnostic language manner that helps programmers to understand and modify it.

Based on that specification, several tools will help you to automatically generate the code that exposes that service, the code consuming it, and even the documentation about it.

Why should I use OpenAPI?

Automatization.

The feature that got our attention to invest time in OpenAPI was the ability to generate the API clients automatically, so we don’t have to bother anymore about model changes and parsing issues for an updated response. Instead of that, once the specification is modified, we run our client generator, and our project is ready to be using the latest changes offered.
You may end up changing some parts of your code to adopt that new client changes, but that’s something you would have to do anyway.

If your API client is generated automatically out of your project, it can be integrated, handled, and consumed like any other third party dependency. Besides that, it avoids all the usual boilerplate you have to program in every project.

OpenAPI can generate the code for most of the programming languages out there, so once you’ve defined the API, you can build in a matter of seconds the client for iOS and Android, to name some platforms.

Single point of truth.

Once you describe your API (that means endpoints, objects, path, etc.) using one single file, you could convert that description into a specific implementation; it does not matter if it’s server-side or client-side. That code will be a product of that description, once you change it there, all the “artifacts” produced out of that file could be regenerate to be used.

That avoids API integration failures like errors parsing invalid responses due to a misalignment between the back-end-offered API and the client-consumed API.

Definition first.

Suppose you decide to go all the way down with OpenAPI and produce the API integration automatically for both the backend and the clients; you will be forced to define your API before implementing anything about it, in any of the sides of it, obtaining a 100% framework biases-free API.

What does it mean? It means that the API definition will be the product of a well-thought process instead of just returning the models the backend already have around. This will force both sides to adapt themselves to work with the API being defined; this approach will put in a 50/50 relationship the client/server weight to describe how they communicate.

Another benefit of having the API definition first is that you can implement both sides without interacting with each other. As you know, there is a contract that is being respected at both sides of the API. If you are implementing a mobile client, you can even develop your tests using HTTP stubs to respond with responses that will be the same as the server will respond.

100% Human readable with the documentation always up-to-date.

The OpenAPI definition file can be described in JSON or YAML, being both quite easy to read as a human and easy to modify if required. This is quite important. It’s way easier to discuss how to make some changes over an easy-to-read document than discuss those changes over a specific programming language or framework.

There is something worse than having no documentation, and that is having out-of-date documentation. As a side-effect of the single point of truth, if you whole API specification is kept in just one format, and several tools can automatically process it, and one of that tools is the documentation generator, so your API documentation (even if it is just for internal usage) won’t be outdated ever again.

Industry standard.

OpenAPI is the current defacto industry standard for API definition, so offering your API using this specification guarantees that any other company will be able to use your services out-of-the-box without any extra setup. That could seem uninteresting for a lot of companies that create their API to be closed, but this technology does not force you to open anything, it will help you to have your API specified using a well-known tool so it can be published if required.

Open-Closed principle down to the roots.

What if I need a specific implementation for my client/server, and it’s not present in the current languages? No problem at all, you can define your own template.
OpenAPI under the hood will use a templating-engine to transform any custom template into some source code. This isn’t as easy as invoking it for Kotlin or Scala, but you can create your generation without substantial modification in the generator.

What’s next?

In the next blog post, we will define a basic API to show how this technology work, and we will generate the API interface for a Spring Boot server and an iOS client that will consume it.

Photo by Neven Krcmarek on Unsplash

Continue Reading Why you should be using OpenAPI right now?

iOS UI development, ludicrously fast.

iOS UI development, ludicrously fast.

One of the biggest complaints you can find between iOS developers is that sometimes, the feedback loop you have when you are doing some fine-tuning of the UI is long. It produces a new Swift compilation, creates a new binary, then the app gets deployed to the simulator, once that’s done, the system will start the app, and then you will be able to navigate to the right screen to check if those small changes are ok.

Sounds familiar?

Meanwhile, you can see your colleges developing websites or React Native apps that they get feedback almost immediately, and they can even modify the UI with a designer in “real-time.”

Feel any envy yet?

What if I tell you that in iOS, we can achieve something similar to that with almost no effort? Would you believe me?

In Karumi, we’ve been playing a bit with a tool that will help us to hot-swap our code so we can shrink our feedback loop duration to just a couple of seconds.

Injection III to the rescue.

This tool created by John Holdsworth will be the one doing all the magic under the hood; it will be checking which files are being changed, compile them, and dynamically insert that code in your running app. Let’s create a tiny example so we can test how this works.

First, we need to install this app from the AppStore and run it.

HotSwapp.

So, let’s create a brand new iOS project, a “Single View App” with Swift and Storyboards, nothing fancy.

Although Injection III has no issues with Storyboards and xibs, I do ( 😬 ), so let’s get rid of the main storyboard and modify our

ViewController

to contain a label center on the screen.

Now it’s time to setup Injection III to be able to edit our label in real-time.

First, we have to load a bundle into our app that will help us with the method swizzling. In our

AppDelegate

we will add the following lines:


func application(_ application: UIApplication,
                     didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
         ...
    #if DEBUG
        Bundle(path: "/Applications/InjectionIII.app/Contents/Resources/iOSInjection.bundle")?.load()
     #endif
        ...
    return true
}

then, once the Injection III app is running, we have to open our project in it so it can track any changes in our files.

Re-run your app, and you should see something like:


💉 Injection connected 👍
💉 Watching /Users/Fran/Development/HotSwapp/**

That means that your app is ready to handle code injection at runtime, let’s give it a go. Without stopping the app, change the label text color and save it.

Your Xcode output will display something like:


💉 *** Compiling /Users/Fran/Development/HotSwapp/HotSwapp/ViewController.swift ***
💉 Loading .dylib ...
objc[7606]: Class _TtC8HotSwapp14ViewController is implemented in both /Users/Fran/Library/Developer/CoreSimulator/Devices/5625C398-4862-4C4E-A5AF-E51A78D1113F/data/Containers/Bundle/Application/BDCBDDA4-A09B-4D72-8048-C24FF1193279/HotSwapp.app/HotSwapp (0x101d72a10) and /Users/Fran/Library/Containers/com.johnholdsworth.InjectionIII/Data/eval101.dylib (0x104b19278). One of the two will be used. Which one is undefined.
💉 Loaded .dylib - Ignore any duplicate class warning ^
💉 Injected 'ViewController'

But your app label keeps having the same color, what’s going on?

Your app has a new code, but you have to respond to that change. Create a new file, called it

UIViewController+HotSwap.swift

and add this content:


import UIKit

#if DEBUG
    extension UIViewController {
        @objc func injected() {
            for subview in view.subviews {
                subview.removeFromSuperview()
            }
            if let sublayers = self.view.layer.sublayers {
                for sublayer in sublayers {
                    sublayer.removeFromSuperlayer()
                }
            }

            viewDidLoad()
        }
    }
#endif

What this method is doing is removing all views and layers from your view controller and will invoke the viewDidLoad method again. Stop your app, and rerun it, now it will show the new color.

Now, change the label color and save it.

🎉🎉🎉

Without stopping it, replace one of the constraints to adjust the label to the left border. Once you save it, in one second, the UI will be reflecting that change.

Now imagine that instead of this app, how this could improve your development speed in some scenarios with a big app, with thousands of lines of code with a lot of third parties dependencies.

iOS UI development, ludicrously fast.

Our experience so far.

After using this for a few weeks, we would like to share with you what we’ve learned about this so you can get up to speed without making the same mistakes we did.

  • Check the documentation from the project.
  • This does not work well when there are new methods or properties; in those cases, rebuild the whole app. What we do is define upfront the methods we are going to need, and then we fill them with the logic.
  • Do not create your views outside the viewDidLoad method; otherwise after the first run, the UI could end up in an invalid state. Keep this in mind, viewDidLoad should init every view and their constraints.
  • You cannot use this on a real device.
  • Code swapping does not get along code coverage, so we recommend you to keep a different scheme for the usage of Injection III while you are fine-tuning your UI.

References

Photo by Jean Gerber on Unsplash

Continue Reading iOS UI development, ludicrously fast.

iOS UI development, ludicrously fast.

iOS UI development, ludicrously fast.

One of the biggest complaints you can find between iOS developers is that sometimes, the feedback loop you have when you are doing some fine-tuning of the UI is long. It produces a new Swift compilation, creates a new binary, then the app gets deployed to the simulator, once that’s done, the system will start the app, and then you will be able to navigate to the right screen to check if those small changes are ok.

Sounds familiar?

Meanwhile, you can see your colleges developing websites or React Native apps that they get feedback almost immediately, and they can even modify the UI with a designer in “real-time.”

Feel any envy yet?

What if I tell you that in iOS, we can achieve something similar to that with almost no effort? Would you believe me?

In Karumi, we’ve been playing a bit with a tool that will help us to hot-swap our code so we can shrink our feedback loop duration to just a couple of seconds.

Injection III to the rescue.

This tool created by John Holdsworth will be the one doing all the magic under the hood; it will be checking which files are being changed, compile them, and dynamically insert that code in your running app. Let’s create a tiny example so we can test how this works.

First, we need to install this app from the AppStore and run it.

HotSwapp.

So, let’s create a brand new iOS project, a “Single View App” with Swift and Storyboards, nothing fancy.

Although Injection III has no issues with Storyboards and xibs, I do ( 😬 ), so let’s get rid of the main storyboard and modify our

ViewController

to contain a label center on the screen.

Now it’s time to setup Injection III to be able to edit our label in real-time.

First, we have to load a bundle into our app that will help us with the method swizzling. In our

AppDelegate

we will add the following lines:


func application(_ application: UIApplication,
                     didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
         ...
    #if DEBUG
        Bundle(path: "/Applications/InjectionIII.app/Contents/Resources/iOSInjection.bundle")?.load()
     #endif
        ...
    return true
}

then, once the Injection III app is running, we have to open our project in it so it can track any changes in our files.

Re-run your app, and you should see something like:


💉 Injection connected 👍
💉 Watching /Users/Fran/Development/HotSwapp/**

That means that your app is ready to handle code injection at runtime, let’s give it a go. Without stopping the app, change the label text color and save it.

Your Xcode output will display something like:


💉 *** Compiling /Users/Fran/Development/HotSwapp/HotSwapp/ViewController.swift ***
💉 Loading .dylib ...
objc[7606]: Class _TtC8HotSwapp14ViewController is implemented in both /Users/Fran/Library/Developer/CoreSimulator/Devices/5625C398-4862-4C4E-A5AF-E51A78D1113F/data/Containers/Bundle/Application/BDCBDDA4-A09B-4D72-8048-C24FF1193279/HotSwapp.app/HotSwapp (0x101d72a10) and /Users/Fran/Library/Containers/com.johnholdsworth.InjectionIII/Data/eval101.dylib (0x104b19278). One of the two will be used. Which one is undefined.
💉 Loaded .dylib - Ignore any duplicate class warning ^
💉 Injected 'ViewController'

But your app label keeps having the same color, what’s going on?

Your app has a new code, but you have to respond to that change. Create a new file, called it

UIViewController+HotSwap.swift

and add this content:


import UIKit

#if DEBUG
    extension UIViewController {
        @objc func injected() {
            for subview in view.subviews {
                subview.removeFromSuperview()
            }
            if let sublayers = self.view.layer.sublayers {
                for sublayer in sublayers {
                    sublayer.removeFromSuperlayer()
                }
            }

            viewDidLoad()
        }
    }
#endif

What this method is doing is removing all views and layers from your view controller and will invoke the viewDidLoad method again. Stop your app, and rerun it, now it will show the new color.

Now, change the label color and save it.

🎉🎉🎉

Without stopping it, replace one of the constraints to adjust the label to the left border. Once you save it, in one second, the UI will be reflecting that change.

Now imagine that instead of this app, how this could improve your development speed in some scenarios with a big app, with thousands of lines of code with a lot of third parties dependencies.

iOS UI development, ludicrously fast.

Our experience so far.

After using this for a few weeks, we would like to share with you what we’ve learned about this so you can get up to speed without making the same mistakes we did.

  • Check the documentation from the project.
  • This does not work well when there are new methods or properties; in those cases, rebuild the whole app. What we do is define upfront the methods we are going to need, and then we fill them with the logic.
  • Do not create your views outside the viewDidLoad method; otherwise after the first run, the UI could end up in an invalid state. Keep this in mind, viewDidLoad should init every view and their constraints.
  • You cannot use this on a real device.
  • Code swapping does not get along code coverage, so we recommend you to keep a different scheme for the usage of Injection III while you are fine-tuning your UI.

References

Photo by Jean Gerber on Unsplash

Continue Reading iOS UI development, ludicrously fast.

iOS UI development, ludicrously fast.

iOS UI development, ludicrously fast.

One of the biggest complaints you can find between iOS developers is that sometimes, the feedback loop you have when you are doing some fine-tuning of the UI is long. It produces a new Swift compilation, creates a new binary, then the app gets deployed to the simulator, once that’s done, the system will start the app, and then you will be able to navigate to the right screen to check if those small changes are ok.

Sounds familiar?

Meanwhile, you can see your colleges developing websites or React Native apps that they get feedback almost immediately, and they can even modify the UI with a designer in “real-time.”

Feel any envy yet?

What if I tell you that in iOS, we can achieve something similar to that with almost no effort? Would you believe me?

In Karumi, we’ve been playing a bit with a tool that will help us to hot-swap our code so we can shrink our feedback loop duration to just a couple of seconds.

Injection III to the rescue.

This tool created by John Holdsworth will be the one doing all the magic under the hood; it will be checking which files are being changed, compile them, and dynamically insert that code in your running app. Let’s create a tiny example so we can test how this works.

First, we need to install this app from the AppStore and run it.

HotSwapp.

So, let’s create a brand new iOS project, a “Single View App” with Swift and Storyboards, nothing fancy.

Although Injection III has no issues with Storyboards and xibs, I do ( 😬 ), so let’s get rid of the main storyboard and modify our

ViewController

to contain a label center on the screen.

Now it’s time to setup Injection III to be able to edit our label in real-time.

First, we have to load a bundle into our app that will help us with the method swizzling. In our

AppDelegate

we will add the following lines:


func application(_ application: UIApplication,
                     didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
         ...
    #if DEBUG
        Bundle(path: "/Applications/InjectionIII.app/Contents/Resources/iOSInjection.bundle")?.load()
     #endif
        ...
    return true
}

then, once the Injection III app is running, we have to open our project in it so it can track any changes in our files.

Re-run your app, and you should see something like:


💉 Injection connected 👍
💉 Watching /Users/Fran/Development/HotSwapp/**

That means that your app is ready to handle code injection at runtime, let’s give it a go. Without stopping the app, change the label text color and save it.

Your Xcode output will display something like:


💉 *** Compiling /Users/Fran/Development/HotSwapp/HotSwapp/ViewController.swift ***
💉 Loading .dylib ...
objc[7606]: Class _TtC8HotSwapp14ViewController is implemented in both /Users/Fran/Library/Developer/CoreSimulator/Devices/5625C398-4862-4C4E-A5AF-E51A78D1113F/data/Containers/Bundle/Application/BDCBDDA4-A09B-4D72-8048-C24FF1193279/HotSwapp.app/HotSwapp (0x101d72a10) and /Users/Fran/Library/Containers/com.johnholdsworth.InjectionIII/Data/eval101.dylib (0x104b19278). One of the two will be used. Which one is undefined.
💉 Loaded .dylib - Ignore any duplicate class warning ^
💉 Injected 'ViewController'

But your app label keeps having the same color, what’s going on?

Your app has a new code, but you have to respond to that change. Create a new file, called it

UIViewController+HotSwap.swift

and add this content:


import UIKit

#if DEBUG
    extension UIViewController {
        @objc func injected() {
            for subview in view.subviews {
                subview.removeFromSuperview()
            }
            if let sublayers = self.view.layer.sublayers {
                for sublayer in sublayers {
                    sublayer.removeFromSuperlayer()
                }
            }

            viewDidLoad()
        }
    }
#endif

What this method is doing is removing all views and layers from your view controller and will invoke the viewDidLoad method again. Stop your app, and rerun it, now it will show the new color.

Now, change the label color and save it.

🎉🎉🎉

Without stopping it, replace one of the constraints to adjust the label to the left border. Once you save it, in one second, the UI will be reflecting that change.

Now imagine that instead of this app, how this could improve your development speed in some scenarios with a big app, with thousands of lines of code with a lot of third parties dependencies.

iOS UI development, ludicrously fast.

Our experience so far.

After using this for a few weeks, we would like to share with you what we’ve learned about this so you can get up to speed without making the same mistakes we did.

  • Check the documentation from the project.
  • This does not work well when there are new methods or properties; in those cases, rebuild the whole app. What we do is define upfront the methods we are going to need, and then we fill them with the logic.
  • Do not create your views outside the viewDidLoad method; otherwise after the first run, the UI could end up in an invalid state. Keep this in mind, viewDidLoad should init every view and their constraints.
  • You cannot use this on a real device.
  • Code swapping does not get along code coverage, so we recommend you to keep a different scheme for the usage of Injection III while you are fine-tuning your UI.

References

Photo by Jean Gerber on Unsplash

Continue Reading iOS UI development, ludicrously fast.

iOS UI development, ludicrously fast.

iOS UI development, ludicrously fast.

One of the biggest complaints you can find between iOS developers is that sometimes, the feedback loop you have when you are doing some fine-tuning of the UI is long. It produces a new Swift compilation, creates a new binary, then the app gets deployed to the simulator, once that’s done, the system will start the app, and then you will be able to navigate to the right screen to check if those small changes are ok.

Sounds familiar?

Meanwhile, you can see your colleges developing websites or React Native apps that they get feedback almost immediately, and they can even modify the UI with a designer in “real-time.”

Feel any envy yet?

What if I tell you that in iOS, we can achieve something similar to that with almost no effort? Would you believe me?

In Karumi, we’ve been playing a bit with a tool that will help us to hot-swap our code so we can shrink our feedback loop duration to just a couple of seconds.

Injection III to the rescue.

This tool created by John Holdsworth will be the one doing all the magic under the hood; it will be checking which files are being changed, compile them, and dynamically insert that code in your running app. Let’s create a tiny example so we can test how this works.

First, we need to install this app from the AppStore and run it.

HotSwapp.

So, let’s create a brand new iOS project, a “Single View App” with Swift and Storyboards, nothing fancy.

Although Injection III has no issues with Storyboards and xibs, I do ( 😬 ), so let’s get rid of the main storyboard and modify our

ViewController

to contain a label center on the screen.

Now it’s time to setup Injection III to be able to edit our label in real-time.

First, we have to load a bundle into our app that will help us with the method swizzling. In our

AppDelegate

we will add the following lines:


func application(_ application: UIApplication,
                     didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
         ...
    #if DEBUG
        Bundle(path: "/Applications/InjectionIII.app/Contents/Resources/iOSInjection.bundle")?.load()
     #endif
        ...
    return true
}

then, once the Injection III app is running, we have to open our project in it so it can track any changes in our files.

Re-run your app, and you should see something like:


💉 Injection connected 👍
💉 Watching /Users/Fran/Development/HotSwapp/**

That means that your app is ready to handle code injection at runtime, let’s give it a go. Without stopping the app, change the label text color and save it.

Your Xcode output will display something like:


💉 *** Compiling /Users/Fran/Development/HotSwapp/HotSwapp/ViewController.swift ***
💉 Loading .dylib ...
objc[7606]: Class _TtC8HotSwapp14ViewController is implemented in both /Users/Fran/Library/Developer/CoreSimulator/Devices/5625C398-4862-4C4E-A5AF-E51A78D1113F/data/Containers/Bundle/Application/BDCBDDA4-A09B-4D72-8048-C24FF1193279/HotSwapp.app/HotSwapp (0x101d72a10) and /Users/Fran/Library/Containers/com.johnholdsworth.InjectionIII/Data/eval101.dylib (0x104b19278). One of the two will be used. Which one is undefined.
💉 Loaded .dylib - Ignore any duplicate class warning ^
💉 Injected 'ViewController'

But your app label keeps having the same color, what’s going on?

Your app has a new code, but you have to respond to that change. Create a new file, called it

UIViewController+HotSwap.swift

and add this content:


import UIKit

#if DEBUG
    extension UIViewController {
        @objc func injected() {
            for subview in view.subviews {
                subview.removeFromSuperview()
            }
            if let sublayers = self.view.layer.sublayers {
                for sublayer in sublayers {
                    sublayer.removeFromSuperlayer()
                }
            }

            viewDidLoad()
        }
    }
#endif

What this method is doing is removing all views and layers from your view controller and will invoke the viewDidLoad method again. Stop your app, and rerun it, now it will show the new color.

Now, change the label color and save it.

🎉🎉🎉

Without stopping it, replace one of the constraints to adjust the label to the left border. Once you save it, in one second, the UI will be reflecting that change.

Now imagine that instead of this app, how this could improve your development speed in some scenarios with a big app, with thousands of lines of code with a lot of third parties dependencies.

iOS UI development, ludicrously fast.

Our experience so far.

After using this for a few weeks, we would like to share with you what we’ve learned about this so you can get up to speed without making the same mistakes we did.

  • Check the documentation from the project.
  • This does not work well when there are new methods or properties; in those cases, rebuild the whole app. What we do is define upfront the methods we are going to need, and then we fill them with the logic.
  • Do not create your views outside the viewDidLoad method; otherwise after the first run, the UI could end up in an invalid state. Keep this in mind, viewDidLoad should init every view and their constraints.
  • You cannot use this on a real device.
  • Code swapping does not get along code coverage, so we recommend you to keep a different scheme for the usage of Injection III while you are fine-tuning your UI.

References

Photo by Jean Gerber on Unsplash

Continue Reading iOS UI development, ludicrously fast.

Lambda World 2019

Lambda World 2019

2019 is the fifth year in a row that a functional programming event is gathering more than 600 people. In the beautiful city of Cádiz. All here to learn about this remarkable coding paradigm. If you couldn’t attend or you want to know about our experience in this event, keep reading. 👇

Lambda World 2019

This year, Jorge and I were in Cádiz since the very first day. The schedule for the Thursday event was exciting. During the morning, an unconference where anyone could propose a lighting talk took place. It was super interesting to see how awesome developers from many different companies decided to talk about topics like:

For me, the most interesting part was the talk by Tapio, where he reviewed how using type classes, we can code generic pure functional programs.

After the unconference, we decided it was time to type and move our fingers, so we went to the workshops. We decided to go to two workshops with different topics, the first one about testing, and the second one about how to build micro-services using a tool named Mu.

The first one was just theory. We had no time to code, but we reviewed how, using property-based testing, we could create programs to test our programs using randomly generated data. The workshop’s host, Adam Rosien, did it great explaining every single detail related to the usage of Scala Check and the most important part: how to think about your software properties. If you don’t know what’s property-based testing about we recommend you to read our blog post series about it.

The second one was breathtaking. Adrián Ramirez and Pepe García explained during almost 2 hours how using an Avro or Open API definition, they could generate a client and a server for the described service using GRPC and basing the implementation on tagless final 🤯. They used mu, a tool 47 Degrees is actively developing, which is designed to create purely functional micro-services. It was interesting to see how the generation of client and server of the micro-service they were building was really similar to the API client generations we’ve been using for a lot of our projects.

Lambda World 2019

After the workshops, we only had left the first keynote of the event. Martin Odersky explained how the implicits feature in Scala is going to be in the next Scala version. It was awesome to see how the creator of the language reviewed the mistakes they made when implementing implicits at the very beginning, the usage of this powerful tool, and how they’ve proposed a different implementation for Scala 3 trying to solve the main pain points. It was mind-blowing when Martin showed us the analytics of the implicits feature usage in Scala projects. 98% of the Scala software uses them!!! 😱

Lambda World 2019

This was just the first day 😱. Bear with us, the second day got way better!

The second day of this conference was full of talks. From Category Theory to an awesome review of how effects are implemented in functional programming. These are the talks we attend during the second day:

Lambda World 2019

There are interesting details for all of them, but we’d like to review a bunch of these talks:

  • Optimising your code with math by April Gonçalves showed us how advanced math concepts are handy when coding. April showed how, using category theory and equational reasoning, we can write better code. Who said maths weren’t needed?
  • Arrow Meta talk, by Raúl Raja and Simon Vergauwen, was also a game-changing talk. The introduction to the new Arrow component just shown us how the life of Kotlin developers is going to change from now on. Thanks to the meta-programming library they’ve built, any developer will be able to change the way kotlin works, providing awesome support for the IntelliJ IDEA IDEs by just using Gradle Compiler Plugins. This is awesome for FP devs, but also interesting for OOP developers. Take a look at this thread with some info about it.
  • Robert M. Avram just surprised every attendee with an excellent story about the effects management in functional programming. His talk was so detailed, and the way the information was delivered was just astonishing. Take a look at this short video, please.

After the closing keynote, the talks day was over, and we only had left one thing. The awesome closing party!! We went to Santa Catalina’s Castle to have fun with friends and talk about the conference.

Lambda World 2019

Overall, Lambda World is an awesome event if you want to learn about Functional Programming. The city where the event is organized is beautiful, the organization takes care of every detail, and the level of the speakers and the talks is world-class. For the next year we’d love to see more talks related to the application of functional programming in the industry or how FP is used to solve a concrete problem, should we send a talk proposal for the next year? 🤔 Who knows, maybe we are the speakers in the next edition! We hope we’ll see you all in the 6th Lambda World edition. 🤘

Continue Reading Lambda World 2019

Lambda World 2019

Lambda World 2019

2019 is the fifth year in a row that a functional programming event is gathering more than 600 people. In the beautiful city of Cádiz. All here to learn about this remarkable coding paradigm. If you couldn’t attend or you want to know about our experience in this event, keep reading. 👇

Lambda World 2019

This year, Jorge and I were in Cádiz since the very first day. The schedule for the Thursday event was exciting. During the morning, an unconference where anyone could propose a lighting talk took place. It was super interesting to see how awesome developers from many different companies decided to talk about topics like:

For me, the most interesting part was the talk by Tapio, where he reviewed how using type classes, we can code generic pure functional programs.

After the unconference, we decided it was time to type and move our fingers, so we went to the workshops. We decided to go to two workshops with different topics, the first one about testing, and the second one about how to build micro-services using a tool named Mu.

The first one was just theory. We had no time to code, but we reviewed how, using property-based testing, we could create programs to test our programs using randomly generated data. The workshop’s host, Adam Rosien, did it great explaining every single detail related to the usage of Scala Check and the most important part: how to think about your software properties. If you don’t know what’s property-based testing about we recommend you to read our blog post series about it.

The second one was breathtaking. Adrián Ramirez and Pepe García explained during almost 2 hours how using an Avro or Open API definition, they could generate a client and a server for the described service using GRPC and basing the implementation on tagless final 🤯. They used mu, a tool 47 Degrees is actively developing, which is designed to create purely functional micro-services. It was interesting to see how the generation of client and server of the micro-service they were building was really similar to the API client generations we’ve been using for a lot of our projects.

Lambda World 2019

After the workshops, we only had left the first keynote of the event. Martin Odersky explained how the implicits feature in Scala is going to be in the next Scala version. It was awesome to see how the creator of the language reviewed the mistakes they made when implementing implicits at the very beginning, the usage of this powerful tool, and how they’ve proposed a different implementation for Scala 3 trying to solve the main pain points. It was mind-blowing when Martin showed us the analytics of the implicits feature usage in Scala projects. 98% of the Scala software uses them!!! 😱

Lambda World 2019

This was just the first day 😱. Bear with us, the second day got way better!

The second day of this conference was full of talks. From Category Theory to an awesome review of how effects are implemented in functional programming. These are the talks we attend during the second day:

Lambda World 2019

There are interesting details for all of them, but we’d like to review a bunch of these talks:

  • Optimising your code with math by April Gonçalves showed us how advanced math concepts are handy when coding. April showed how, using category theory and equational reasoning, we can write better code. Who said maths weren’t needed?
  • Arrow Meta talk, by Raúl Raja and Simon Vergauwen, was also a game-changing talk. The introduction to the new Arrow component just shown us how the life of Kotlin developers is going to change from now on. Thanks to the meta-programming library they’ve built, any developer will be able to change the way kotlin works, providing awesome support for the IntelliJ IDEA IDEs by just using Gradle Compiler Plugins. This is awesome for FP devs, but also interesting for OOP developers. Take a look at this thread with some info about it.
  • Robert M. Avram just surprised every attendee with an excellent story about the effects management in functional programming. His talk was so detailed, and the way the information was delivered was just astonishing. Take a look at this short video, please.

After the closing keynote, the talks day was over, and we only had left one thing. The awesome closing party!! We went to Santa Catalina’s Castle to have fun with friends and talk about the conference.

Lambda World 2019

Overall, Lambda World is an awesome event if you want to learn about Functional Programming. The city where the event is organized is beautiful, the organization takes care of every detail, and the level of the speakers and the talks is world-class. For the next year we’d love to see more talks related to the application of functional programming in the industry or how FP is used to solve a concrete problem, should we send a talk proposal for the next year? 🤔 Who knows, maybe we are the speakers in the next edition! We hope we’ll see you all in the 6th Lambda World edition. 🤘

Continue Reading Lambda World 2019

Lambda World 2019

Lambda World 2019

2019 is the fifth year in a row that a functional programming event is gathering more than 600 people. In the beautiful city of Cádiz. All here to learn about this remarkable coding paradigm. If you couldn’t attend or you want to know about our experience in this event, keep reading. 👇

Lambda World 2019

This year, Jorge and I were in Cádiz since the very first day. The schedule for the Thursday event was exciting. During the morning, an unconference where anyone could propose a lighting talk took place. It was super interesting to see how awesome developers from many different companies decided to talk about topics like:

For me, the most interesting part was the talk by Tapio, where he reviewed how using type classes, we can code generic pure functional programs.

After the unconference, we decided it was time to type and move our fingers, so we went to the workshops. We decided to go to two workshops with different topics, the first one about testing, and the second one about how to build micro-services using a tool named Mu.

The first one was just theory. We had no time to code, but we reviewed how, using property-based testing, we could create programs to test our programs using randomly generated data. The workshop’s host, Adam Rosien, did it great explaining every single detail related to the usage of Scala Check and the most important part: how to think about your software properties. If you don’t know what’s property-based testing about we recommend you to read our blog post series about it.

The second one was breathtaking. Adrián Ramirez and Pepe García explained during almost 2 hours how using an Avro or Open API definition, they could generate a client and a server for the described service using GRPC and basing the implementation on tagless final 🤯. They used mu, a tool 47 Degrees is actively developing, which is designed to create purely functional micro-services. It was interesting to see how the generation of client and server of the micro-service they were building was really similar to the API client generations we’ve been using for a lot of our projects.

Lambda World 2019

After the workshops, we only had left the first keynote of the event. Martin Odersky explained how the implicits feature in Scala is going to be in the next Scala version. It was awesome to see how the creator of the language reviewed the mistakes they made when implementing implicits at the very beginning, the usage of this powerful tool, and how they’ve proposed a different implementation for Scala 3 trying to solve the main pain points. It was mind-blowing when Martin showed us the analytics of the implicits feature usage in Scala projects. 98% of the Scala software uses them!!! 😱

Lambda World 2019

This was just the first day 😱. Bear with us, the second day got way better!

The second day of this conference was full of talks. From Category Theory to an awesome review of how effects are implemented in functional programming. These are the talks we attend during the second day:

Lambda World 2019

There are interesting details for all of them, but we’d like to review a bunch of these talks:

  • Optimising your code with math by April Gonçalves showed us how advanced math concepts are handy when coding. April showed how, using category theory and equational reasoning, we can write better code. Who said maths weren’t needed?
  • Arrow Meta talk, by Raúl Raja and Simon Vergauwen, was also a game-changing talk. The introduction to the new Arrow component just shown us how the life of Kotlin developers is going to change from now on. Thanks to the meta-programming library they’ve built, any developer will be able to change the way kotlin works, providing awesome support for the IntelliJ IDEA IDEs by just using Gradle Compiler Plugins. This is awesome for FP devs, but also interesting for OOP developers. Take a look at this thread with some info about it.
  • Robert M. Avram just surprised every attendee with an excellent story about the effects management in functional programming. His talk was so detailed, and the way the information was delivered was just astonishing. Take a look at this short video, please.

After the closing keynote, the talks day was over, and we only had left one thing. The awesome closing party!! We went to Santa Catalina’s Castle to have fun with friends and talk about the conference.

Lambda World 2019

Overall, Lambda World is an awesome event if you want to learn about Functional Programming. The city where the event is organized is beautiful, the organization takes care of every detail, and the level of the speakers and the talks is world-class. For the next year we’d love to see more talks related to the application of functional programming in the industry or how FP is used to solve a concrete problem, should we send a talk proposal for the next year? 🤔 Who knows, maybe we are the speakers in the next edition! We hope we’ll see you all in the 6th Lambda World edition. 🤘

Continue Reading Lambda World 2019

Lambda World 2019

Lambda World 2019

2019 is the fifth year in a row that a functional programming event is gathering more than 600 people. In the beautiful city of Cádiz. All here to learn about this remarkable coding paradigm. If you couldn’t attend or you want to know about our experience in this event, keep reading. 👇

Lambda World 2019

This year, Jorge and I were in Cádiz since the very first day. The schedule for the Thursday event was exciting. During the morning, an unconference where anyone could propose a lighting talk took place. It was super interesting to see how awesome developers from many different companies decided to talk about topics like:

For me, the most interesting part was the talk by Tapio, where he reviewed how using type classes, we can code generic pure functional programs.

After the unconference, we decided it was time to type and move our fingers, so we went to the workshops. We decided to go to two workshops with different topics, the first one about testing, and the second one about how to build micro-services using a tool named Mu.

The first one was just theory. We had no time to code, but we reviewed how, using property-based testing, we could create programs to test our programs using randomly generated data. The workshop’s host, Adam Rosien, did it great explaining every single detail related to the usage of Scala Check and the most important part: how to think about your software properties. If you don’t know what’s property-based testing about we recommend you to read our blog post series about it.

The second one was breathtaking. Adrián Ramirez and Pepe García explained during almost 2 hours how using an Avro or Open API definition, they could generate a client and a server for the described service using GRPC and basing the implementation on tagless final 🤯. They used mu, a tool 47 Degrees is actively developing, which is designed to create purely functional micro-services. It was interesting to see how the generation of client and server of the micro-service they were building was really similar to the API client generations we’ve been using for a lot of our projects.

Lambda World 2019

After the workshops, we only had left the first keynote of the event. Martin Odersky explained how the implicits feature in Scala is going to be in the next Scala version. It was awesome to see how the creator of the language reviewed the mistakes they made when implementing implicits at the very beginning, the usage of this powerful tool, and how they’ve proposed a different implementation for Scala 3 trying to solve the main pain points. It was mind-blowing when Martin showed us the analytics of the implicits feature usage in Scala projects. 98% of the Scala software uses them!!! 😱

Lambda World 2019

This was just the first day 😱. Bear with us, the second day got way better!

The second day of this conference was full of talks. From Category Theory to an awesome review of how effects are implemented in functional programming. These are the talks we attend during the second day:

Lambda World 2019

There are interesting details for all of them, but we’d like to review a bunch of these talks:

  • Optimising your code with math by April Gonçalves showed us how advanced math concepts are handy when coding. April showed how, using category theory and equational reasoning, we can write better code. Who said maths weren’t needed?
  • Arrow Meta talk, by Raúl Raja and Simon Vergauwen, was also a game-changing talk. The introduction to the new Arrow component just shown us how the life of Kotlin developers is going to change from now on. Thanks to the meta-programming library they’ve built, any developer will be able to change the way kotlin works, providing awesome support for the IntelliJ IDEA IDEs by just using Gradle Compiler Plugins. This is awesome for FP devs, but also interesting for OOP developers. Take a look at this thread with some info about it.
  • Robert M. Avram just surprised every attendee with an excellent story about the effects management in functional programming. His talk was so detailed, and the way the information was delivered was just astonishing. Take a look at this short video, please.

After the closing keynote, the talks day was over, and we only had left one thing. The awesome closing party!! We went to Santa Catalina’s Castle to have fun with friends and talk about the conference.

Lambda World 2019

Overall, Lambda World is an awesome event if you want to learn about Functional Programming. The city where the event is organized is beautiful, the organization takes care of every detail, and the level of the speakers and the talks is world-class. For the next year we’d love to see more talks related to the application of functional programming in the industry or how FP is used to solve a concrete problem, should we send a talk proposal for the next year? 🤔 Who knows, maybe we are the speakers in the next edition! We hope we’ll see you all in the 6th Lambda World edition. 🤘

Continue Reading Lambda World 2019

Lambda World 2019

Lambda World 2019

2019 is the fifth year in a row that a functional programming event is gathering more than 600 people. In the beautiful city of Cádiz. All here to learn about this remarkable coding paradigm. If you couldn’t attend or you want to know about our experience in this event, keep reading. 👇

Lambda World 2019

This year, Jorge and I were in Cádiz since the very first day. The schedule for the Thursday event was exciting. During the morning, an unconference where anyone could propose a lighting talk took place. It was super interesting to see how awesome developers from many different companies decided to talk about topics like:

For me, the most interesting part was the talk by Tapio, where he reviewed how using type classes, we can code generic pure functional programs.

After the unconference, we decided it was time to type and move our fingers, so we went to the workshops. We decided to go to two workshops with different topics, the first one about testing, and the second one about how to build micro-services using a tool named Mu.

The first one was just theory. We had no time to code, but we reviewed how, using property-based testing, we could create programs to test our programs using randomly generated data. The workshop’s host, Adam Rosien, did it great explaining every single detail related to the usage of Scala Check and the most important part: how to think about your software properties. If you don’t know what’s property-based testing about we recommend you to read our blog post series about it.

The second one was breathtaking. Adrián Ramirez and Pepe García explained during almost 2 hours how using an Avro or Open API definition, they could generate a client and a server for the described service using GRPC and basing the implementation on tagless final 🤯. They used mu, a tool 47 Degrees is actively developing, which is designed to create purely functional micro-services. It was interesting to see how the generation of client and server of the micro-service they were building was really similar to the API client generations we’ve been using for a lot of our projects.

Lambda World 2019

After the workshops, we only had left the first keynote of the event. Martin Odersky explained how the implicits feature in Scala is going to be in the next Scala version. It was awesome to see how the creator of the language reviewed the mistakes they made when implementing implicits at the very beginning, the usage of this powerful tool, and how they’ve proposed a different implementation for Scala 3 trying to solve the main pain points. It was mind-blowing when Martin showed us the analytics of the implicits feature usage in Scala projects. 98% of the Scala software uses them!!! 😱

Lambda World 2019

This was just the first day 😱. Bear with us, the second day got way better!

The second day of this conference was full of talks. From Category Theory to an awesome review of how effects are implemented in functional programming. These are the talks we attend during the second day:

Lambda World 2019

There are interesting details for all of them, but we’d like to review a bunch of these talks:

  • Optimising your code with math by April Gonçalves showed us how advanced math concepts are handy when coding. April showed how, using category theory and equational reasoning, we can write better code. Who said maths weren’t needed?
  • Arrow Meta talk, by Raúl Raja and Simon Vergauwen, was also a game-changing talk. The introduction to the new Arrow component just shown us how the life of Kotlin developers is going to change from now on. Thanks to the meta-programming library they’ve built, any developer will be able to change the way kotlin works, providing awesome support for the IntelliJ IDEA IDEs by just using Gradle Compiler Plugins. This is awesome for FP devs, but also interesting for OOP developers. Take a look at this thread with some info about it.
  • Robert M. Avram just surprised every attendee with an excellent story about the effects management in functional programming. His talk was so detailed, and the way the information was delivered was just astonishing. Take a look at this short video, please.

After the closing keynote, the talks day was over, and we only had left one thing. The awesome closing party!! We went to Santa Catalina’s Castle to have fun with friends and talk about the conference.

Lambda World 2019

Overall, Lambda World is an awesome event if you want to learn about Functional Programming. The city where the event is organized is beautiful, the organization takes care of every detail, and the level of the speakers and the talks is world-class. For the next year we’d love to see more talks related to the application of functional programming in the industry or how FP is used to solve a concrete problem, should we send a talk proposal for the next year? 🤔 Who knows, maybe we are the speakers in the next edition! We hope we’ll see you all in the 6th Lambda World edition. 🤘

Continue Reading Lambda World 2019

Server as a function with Kotlin – http4k

Server as a function with Kotlin – http4k

Have you ever heard about the concept of “Server as a Function”? The idea is that we write our server application based on just ordinary functions, which is based on a concept outlined in the paper Your Server as a Function written and published by Twitter/Marius Eriksen. In the Kotlin world, the most prominent implementation of this concept is http4k, which the maintainers describe as an “HTTP toolset written in Kotlin with a focus on creating simple, testable APIs”. The best part about it is that http4k applications are just Kotlin functions that we can test straightforwardly. Take a look at this first example:

First http4k server example


val app: HttpHandler = { request: Request -> Response(OK).body(request.body) }
val server = app.asServer(SunHttp(8000)).start()

This code shows a fully functional http4k application consisting of a single Kotlin function

app

which we embedded into a

SunHttp

server, one example of available server implementations we may choose from. Note the type

HttpHandler

here, which represents one of the two essential concepts in the idea of “Server as a Function”:

  • HttpHandler (
    (Request) -> Response

    ): abstraction to process HTTP requests into responses by mapping the first into the latter

  • Filter (
    HttpHandler -> HttpHandler

    ): abstraction to add pre and post-processing like caching, debugging, authentication handling, and more to an

    HttpHandler

    . Filters are composable/stackable

Every http4k application can be composed of

HttpHandler

s in combination with

Filter

s, both of which are simple type aliases for ordinary Kotlin function types. Http4k comes with zero dependencies if we don’t count the Kotlin standard library as one. Since http4k applications, in their pure form, only entail some nested Kotlin functions; there is no reflection or annotation processing involved. As a result, http4k applications can start and stop super quickly which also makes them a reasonable candidate to be deployed on Function-as-a-Service environments (as opposed to e.g., Spring Boot applications).

More advanced http4k application

Let’s take a look at a more advanced example of an http4k server.


val pingPongHandler: HttpHandler = { _ -> Response(OK).body("pong!") }

val greetHandler: HttpHandler = { req: Request ->
    val name: String? = req.query("name")
    Response(OK).body("hello ${name ?: "unknown!"}")
}

val routing: RoutingHttpHandler = routes(
     "/ping" bind GET to pingPongHandler,
     "/greet" bind GET to greetHandler
)

val requestTimeLogger: Filter = Filter { next: HttpHandler ->
     { request: Request ->
         val start = clock.millis()
         val response = next(request)
         val latency = clock.millis() - start
         logger { "Request to ${request.uri} took ${latency}ms" }
         response
     }
}

val app: HttpHandler =
     ResponseFilters.GZip()
     .then(requestTimeLogger)
     .then(routing)

In this snippet, we can see a few exciting things http4k applications may entail. The first two expressions are definitions of

HttpHandler

s, in which the first one takes any response and maps it to an

OK

response containing “pong” in its body. The second handler takes a request, extracts a name, and greets the caller. In the next step, we apply routing to the handlers by assigning one particular route to each handler. As we can see, the

pingPongHandler

is used to serve a client who invokes

/ping

, while the

greetHandler

is used to cover

/greet

.

Routing

Routing in http4k works with arbitrary levels of nesting, which works flawlessly since

routing

itself results in a new

HttpHandler

(strictly speaking, a special kind of type

RoutingHttpHandler

), just like the original ones.

Filters

As mentioned before, the other important concept we want to look at is

Filter

s. For starters, we create a

requestTimeLogger

that intercepts each incoming request by measuring its processing time and logging the elapsed time. Filters can be combined using the

then

method, which allows us to define chains of filters. The corresponding API looks like this:


fun Filter.then(next: Filter): Filter

In the example application above, we add our custom filter to one of the default filters called

GZip

. Once we have combined all our filters, we want to add an

HttpHandler

to our filter chain. Again, there’s a

then

function we can use to do so:


fun Filter.then(next: HttpHandler): HttpHandler

As we can see, this again results in an

HttpHandler

. You all probably got the idea by now – It only needs two simple types to express how an HTTP server should operate.

The shown

GZip

filter is just one of many default filters we may choose from. Others cover concerns like caching, CORS, basic authentication or cookie handling and can be found in the

org.http4k.filter

package.

Calling HttpHandlers

So what did we get out of that nesting which resulted in yet another

HttpHandler

called

app

? Well, this itself does not entail running an actual server yet. However, it describes how requests are handled. We can use this object, as well as other separate

HttpHandler

s and

Filter

s, and invoke it directly (e.g. in our tests). No HTTP required. Let’s see this in action:


//call handler directly
val handlerResponse: Response = pingPongHandler(Request(GET, "/any"))

//call handler through routing
val routingCallResponse: Response = app(Request(GET, "/ping").header("accept-encoding", "gzip"))

app.asServer(Jetty(9000)).start()

Http4k comes with its own implementations of a

Request

and a

Response

, first of which can be used to invoke an

HttpHandler

. Calling the unattractive

pingPongHandler

yields something similar to

HTTP/1.1 200 OK pong!

while calling the final

app

handler gives us a gzipped response due to the applied GZip filter. This call also implies a log informing about the duration of the request:

2019-09-20T21:22:55.300768Z LOG - Request to /ping took 3ms

. Please note that, while it was fine to call

pingPongHandler

with a random URI (

/any

), we had to use the designated

/ping

URI when invoking the routing-backed

app

.
Last, but not least, we start our very own http4k

HttpHandler

as a server on a

Jetty

with port

9000

. Find a list of available server implementations here.

Lenses

One of the things a sophisticated HTTP app has to deal with is taking stuff out and also putting stuff into HTTP messages. When we take parameters out of requests, we also care about validating these values. Http4k comes with a fascinating concept that helps us deal with the stated concerns:

Lenses

.

Basic Definition

Lenses, according to multiple resources, were first used in the Haskell world and are a functional concept that may appear slightly hard to understand. Let me try to describe it in a shallow, understandable manner. Let’s say we have a class

Whole

which comes with different fields

part1

,

part2

, and so on. A lens basically composes a getter and a setter focusing on precisely one part of

Whole

. A

Part1Lens

lens getter would take an instance of

Whole

to return the part it is focused on, i.e.,

part1

. The lens setter, on the other hand, takes a

Whole

along with a value to set the focused part to and then returns a new

Whole

with the updated part. Remember that a lens can be used to both get and set a part of a whole object. Now, let’s learn how this concept helps us with handling HTTP messages.

Lenses in http4k

Following the basic idea of a lens, http4k lenses are bi-directional entities which can be used to either get or set a particular value from/onto an HTTP message. The corresponding API to describe lenses comes in the form of a DSL which also lets us define the requirement (optional vs. mandatory) of the HTTP part we are mounting a lens on. Since HTTP messages are a rather complex container, we can have lenses focusing on different areas of the messages: Query, Header, Path, FormField, Body. Let’s see some examples of how lenses can be created:


// lens focusing on the path variable name
val nameLens = Path.string().of("name")

// lens focusing on a required query parameter city
val requiredQuery = Query.required("city")

// lens focusing on a required and non empty string city
val nonEmptyQuery = Query.nonEmptyString().required("city")

// lens focusing on an optional header Content-Length with type int
val optionalHeader = Header.int().optional("Content-Length")

// lens focusing on text body
val responseBody = Body.string(ContentType.TEXT_PLAIN).toLens()

So far, the API for creating lenses looks more or less straightforward but what about using them on a target? Here’s the pseudo code syntax for
a) Retrieving a value:

<lens>.extract(<target>)

, or

<lens>(<target>)

b) Setting a value:

<lens>.inject(<value>, <target>)

, or

<lens>(<value>, <target>)

Use Lens to Retrieve value from HTTP Request

Reusing the

greet

sample from earlier, let’s modify our code to make use of lenses when retrieving a value:


val nameLens: BiDiLens<Request, String> =
    Query.nonEmptyString().required("name")

val greetHandler: HttpHandler = { req: Request ->
     val name: String = nameLens.extract(req) //or nameLens(req)
     Response(OK).body("hello $name")
}

We create a bidirectional lens focusing on the query part of our message to extract a required and non-empty name from it. Now, if a client happens to call the endpoint without providing a

name

query parameter, the lens automatically returns an error since it was defined as “required” and “nonEmpty”. Please note that, by default, the application exposes much detail to the client announcing the error as

org.http4k.lens.LensFailure: query 'name' must be string

including a detailed stack trace. Rather than that, we want to map all lens errors to HTTP 400 responses which implies that the client provided invalid data. Therefore, http4k offers a

ServerFilters.CatchLensFailure

filter which we can easily activate in our filter chain:


// gzip omitted
val app: HttpHandler = ServerFilters.CatchLensFailure
 .then(requestTimeLogger)
 .then(routing)

Use Lens to Set value in HTTP Request

After looking into extracting values from HTTP messages, how can we use the

nameLens

to set a value in an HTTP request?


val req = Request(GET, "/greet/{name}")
val reqWithName = nameLens.inject("kotlin", req)
// alternatively, http4k offers a with function that can apply multiple lenses at once
val reqWithName = Request(GET, "/greet/{name}").with(
    nameLens of "simon" //, more lenses
)

The example shows how we create an instance of

Request

and inject a value via one or many lenses. We can use the

Lens::inject

function to specify the value we want to set into an arbitrary instance of

Request

. Now that we saw a basic example of a string lens, we want to dig into handling some more advanced JSON content.

JSON handling

We can choose from several JSON implementations, including e.g., the common Gson and Jackson library. I personally prefer Jackson as it comes with a great Kotlin module (Kudos to my friend Jayson Minard 😉). After adding a JSON format module to our application, we can start marshaling objects to and from HTTP messages using lenses. Let’s consider a partially complete REST API that manages persons:


[...]
import org.http4k.format.Jackson.auto

class PersonHandlerProvider(private val service: PersonService) {
    private val personLens: BiDiBodyLens<Person> = Body.auto<Person>().toLens()
    private val personListLens: BiDiBodyLens<List<Person>> = Body.auto<List<Person>>().toLens()

     fun getAllHandler(): HttpHandler = {
             Response(OK).with(
                 personListLens of service.findAll()
             )
        }

     fun postHandler(): HttpHandler = { req ->
             val personToAdd = personLens.extract(req)
             service.add(personToAdd)
             Response(OK)
         }

     //...more
}

In this example, we see a class that provides two handlers representing common actions you would expect from a REST API. The

getAllHandler

fetches all currently stored entities and returns them to the client. We make use of a

BiDiBodyLens<List<Person>>

(BiDirectional) that we created via the

org.http4k.format.Jackson.auto

extension for Jackson. As noted in the http4k documentation, “the auto() method needs to be manually imported as IntelliJ won’t pick it up automatically”. We can use the resulting lens like already shown earlier by providing a value of type

List<Person>

and inject it into an HTTP

Response

as shown in the

getAllHandler

implementation.
The

postHandler

, on the other hand, provides an implementation of an

HttpHandler

, that extracts a

Person

entity from the request and adds it to the storage. Again, we use a lens to extract that JSON entity from the request easily.

This already concludes our sneak peek on lenses. As we saw, lenses are a fantastic tool that lets us extract and inject parts of an HTTP message and also provides simple means of validating those parts. Now, that we have seen the most fundamental concepts of the http4k toolset, let’s consider how we can test such applications.

Testing

Most of the time, when we consider testing applications that sit on top of a web framework, we have to worry about details of that framework which can make testing harder than it should be. Spoiler Alert: This is not quite the case with http4k 🎉

We have already learned that

HttpHandlers

, one of the two core concepts in the http4k toolset, are just regular Kotlin functions mapping requests to responses and even a complete http4k application again is just an

HttpHandler

and thus a callable function. As a result, entire and partial http4k apps can be tested easily and without additional work. Nevertheless, the makers of http4k thought that it would still be helpful to provide some additional modules which support us with testing our applications. One of these modules is

http4k-testing-hamkrest

, which adds a set of Hamkrest matchers, we can use to verify details of message objects more easily.

Http4k Handler Test Example


import com.natpryce.hamkrest.assertion.assertThat
import org.http4k.core.Method
import org.http4k.core.Request
import org.http4k.core.Status
import org.http4k.hamkrest.hasStatus
import org.junit.jupiter.api.Test

class PersonHandlerProviderTest {

    val systemUnderTest = PersonHandlerProvider(PersonService())

    @Test
    fun getAll_handler_can_be_invoked_as_expected(){
        val getAll: HttpHandler = systemUnderTest.getAllHandler()

        val result: Response = getAll(Request(Method.GET, "/some-uri"))

        assertThat(result, hasStatus(Status.OK))
    }
}

This snippet demonstrates a test for the

PersonHandlerProvider

we have worked with earlier already. As shown, it’s pretty straightforward to call an

HttpHandler

with a

Request

object and then use Hamkrest or whatever assertion library you prefer to check the resulting

Response

. Testing

Filter

s, on the other hand, is “harder”. To be honest though, it’s just one tiny thing we need to do on top of what we did with handlers. Filters map one

HttpHandler

into another one by applying some intermediate pre or post-processing. Instead of investigating the mapping between handlers itself, it would be more convenient to again send a

Request

through that filter and look into the resulting

Response

. The good news is: It’s super easy to do just that:

Http4k Filter Test Example


val addExtraHeaderFilter = Filter { next ->
    {
        next(it).header("x-extra-header", "some value")
    }
}

@Test
fun adds_a_special_header() {
    val handler: HttpHandler = addExtraHeaderFilter.then { Response(OK) }

    val response: Response = handler(Request(GET, "/echo"))

    assertThat(response, hasStatus(OK).and(hasHeader("x-extra-header", "some value")))
}

We have a

Filter

called

addExtraHeaderFilter

that adds a custom header to a processed request and then forwards it to the next filter. The goal is to send a simple request through that filter in our test. What we can do, is making the filter a simple

HttpHandler

by adding a dumb

{ Response(OK) }

handler to it via

then

. As a result, we can invoke the newly created handler, now containing our very own filter, and investigate whether the resulting

Response

object contains the new expected header. There we go – both handlers and filters got tested 🙃
To wrap up, I want to say that this was just a quick look at the happy paths of testing http4k apps with mostly familiar tools. It might become necessary to test against the actual running server and verify Responses on a lower level, e.g., comparing the resulting JSON directly. Doing that is also possible and supported via the Approval Testing module. Later in this article, we want to look at the client module of http4k, which again opens up some new possibilities.

Serverless

One of the hottest topics of our time is Serverless computing. You know, that thing where we can run our code on other people’s… servers. One part of it is known as Function as a Service, or FaaS and the most common ones include AWS Lambda, Google Cloud Functions, and Microsoft Azure Functions. The general idea is that these vendors provide a platform where we can deploy our code, and they take care of managing resources and scaling our application on demand. One of the downsides of Serverless is that our functions may be spun down by the platform if it’s not being used until someone wants to use it again, which would require a fresh startup. What does that mean for us? We need to choose target platforms and tools which allow a fast start-up of our application. Spring on the JVM in its classical form, for instance, would probably not be the best tool for that use case. However, as you can image, http4k with its small footprint and super quick start-up times is a great choice. It even comes with native support for AWS Lambda.

I won’t dive much deeper into this topic as part of this article, but I’m planning to write a much more detailed post on what we can do with http4k on a FaaS platform. Stay tuned.

Client as a Function

By now, we have learned how cool http4k is and why it’s a great tool to develop server applications. HTTP Servers don’t make much sense without clients using them, so we want to conclude this article by looking at the other side – Clients as a Function.
The http4k

core

library comes with everything we need to get started with clients. Clients in http4k again are just a special form of an

HttpHandler

, as we can see in this little snippet:


val request = Request(Method.GET, "https://kotlinexpertise.com/sitemap.xml")
val client: HttpHandler = JavaHttpClient()
val response = client(request)

The shown

JavaHttpClient

is the default implementation that comes with the

core

library. If we were to prefer OkHttp, Apache, or Jetty instead, we would find a related module to replace the default. Since we program against interfaces (clients are

HttpHandler

s), it’s not a big deal to swap out implementations at any time. The

core

library obviously comes with several default

Filter

s we can apply to our client which can be found in the

ClientFilters.kt

file that contains stuff like

BasicAuth

,

Gzip

and more stuff you’d expect for a client. The fact that all concepts of http4k servers, including handlers, filters and also lenses, can be reused in http4k clients opens up quite a few possibilities so that it can make much sense to e.g., use the client module to test your servers an vice versa.

Summary and Lookout

I personally learned to appreciate http4k a lot in the last couple of weeks. Once you’ve made yourself comfortable with the basic concepts, it becomes straightforward to develop (which includes testing) server applications quickly. Http4k comes with an incredible list of supported concepts and technologies including OAuth, Swagger, Websockets, XML and many, many more. Its modular nature allows us to add functionality by applying dependencies as needed, and due to its simple base types, it is highly extensible. Http4k is a toolset that allows us to write applications with quick startup times which also makes it a valid alternative when it comes to FaaS and Serverless computing. As if this wasn’t enough, the toolset also includes sophisticated means for writing HTTP clients, which we learned about in the last section. Overall, http4k is a promising technology that you should definitely consider when choosing your next HTTP toolset.

If you want to learn more about Kotlin and its fantastic language features, please have a look at my talk “Diving into advanced language features”.

The post Server as a function with Kotlin – http4k appeared first on Kotlin Expertise Blog.

Continue Reading Server as a function with Kotlin – http4k

Server as a function with Kotlin – http4k

Server as a function with Kotlin – http4k

Have you ever heard about the concept of “Server as a Function”? The idea is that we write our server application based on just ordinary functions, which is based on a concept outlined in the paper Your Server as a Function written and published by Twitter/Marius Eriksen. In the Kotlin world, the most prominent implementation of this concept is http4k, which the maintainers describe as an “HTTP toolset written in Kotlin with a focus on creating simple, testable APIs”. The best part about it is that http4k applications are just Kotlin functions that we can test straightforwardly. Take a look at this first example:

First http4k server example


val app: HttpHandler = { request: Request -> Response(OK).body(request.body) }
val server = app.asServer(SunHttp(8000)).start()

This code shows a fully functional http4k application consisting of a single Kotlin function

app

which we embedded into a

SunHttp

server, one example of available server implementations we may choose from. Note the type

HttpHandler

here, which represents one of the two essential concepts in the idea of “Server as a Function”:

  • HttpHandler (
    (Request) -> Response

    ): abstraction to process HTTP requests into responses by mapping the first into the latter

  • Filter (
    HttpHandler -> HttpHandler

    ): abstraction to add pre and post-processing like caching, debugging, authentication handling, and more to an

    HttpHandler

    . Filters are composable/stackable

Every http4k application can be composed of

HttpHandler

s in combination with

Filter

s, both of which are simple type aliases for ordinary Kotlin function types. Http4k comes with zero dependencies if we don’t count the Kotlin standard library as one. Since http4k applications, in their pure form, only entail some nested Kotlin functions; there is no reflection or annotation processing involved. As a result, http4k applications can start and stop super quickly which also makes them a reasonable candidate to be deployed on Function-as-a-Service environments (as opposed to e.g., Spring Boot applications).

More advanced http4k application

Let’s take a look at a more advanced example of an http4k server.


val pingPongHandler: HttpHandler = { _ -> Response(OK).body("pong!") }

val greetHandler: HttpHandler = { req: Request ->
    val name: String? = req.query("name")
    Response(OK).body("hello ${name ?: "unknown!"}")
}

val routing: RoutingHttpHandler = routes(
     "/ping" bind GET to pingPongHandler,
     "/greet" bind GET to greetHandler
)

val requestTimeLogger: Filter = Filter { next: HttpHandler ->
     { request: Request ->
         val start = clock.millis()
         val response = next(request)
         val latency = clock.millis() - start
         logger { "Request to ${request.uri} took ${latency}ms" }
         response
     }
}

val app: HttpHandler =
     ResponseFilters.GZip()
     .then(requestTimeLogger)
     .then(routing)

In this snippet, we can see a few exciting things http4k applications may entail. The first two expressions are definitions of

HttpHandler

s, in which the first one takes any response and maps it to an

OK

response containing “pong” in its body. The second handler takes a request, extracts a name, and greets the caller. In the next step, we apply routing to the handlers by assigning one particular route to each handler. As we can see, the

pingPongHandler

is used to serve a client who invokes

/ping

, while the

greetHandler

is used to cover

/greet

.

Routing

Routing in http4k works with arbitrary levels of nesting, which works flawlessly since

routing

itself results in a new

HttpHandler

(strictly speaking, a special kind of type

RoutingHttpHandler

), just like the original ones.

Filters

As mentioned before, the other important concept we want to look at is

Filter

s. For starters, we create a

requestTimeLogger

that intercepts each incoming request by measuring its processing time and logging the elapsed time. Filters can be combined using the

then

method, which allows us to define chains of filters. The corresponding API looks like this:


fun Filter.then(next: Filter): Filter

In the example application above, we add our custom filter to one of the default filters called

GZip

. Once we have combined all our filters, we want to add an

HttpHandler

to our filter chain. Again, there’s a

then

function we can use to do so:


fun Filter.then(next: HttpHandler): HttpHandler

As we can see, this again results in an

HttpHandler

. You all probably got the idea by now – It only needs two simple types to express how an HTTP server should operate.

The shown

GZip

filter is just one of many default filters we may choose from. Others cover concerns like caching, CORS, basic authentication or cookie handling and can be found in the

org.http4k.filter

package.

Calling HttpHandlers

So what did we get out of that nesting which resulted in yet another

HttpHandler

called

app

? Well, this itself does not entail running an actual server yet. However, it describes how requests are handled. We can use this object, as well as other separate

HttpHandler

s and

Filter

s, and invoke it directly (e.g. in our tests). No HTTP required. Let’s see this in action:


//call handler directly
val handlerResponse: Response = pingPongHandler(Request(GET, "/any"))

//call handler through routing
val routingCallResponse: Response = app(Request(GET, "/ping").header("accept-encoding", "gzip"))

app.asServer(Jetty(9000)).start()

Http4k comes with its own implementations of a

Request

and a

Response

, first of which can be used to invoke an

HttpHandler

. Calling the unattractive

pingPongHandler

yields something similar to

HTTP/1.1 200 OK pong!

while calling the final

app

handler gives us a gzipped response due to the applied GZip filter. This call also implies a log informing about the duration of the request:

2019-09-20T21:22:55.300768Z LOG - Request to /ping took 3ms

. Please note that, while it was fine to call

pingPongHandler

with a random URI (

/any

), we had to use the designated

/ping

URI when invoking the routing-backed

app

.
Last, but not least, we start our very own http4k

HttpHandler

as a server on a

Jetty

with port

9000

. Find a list of available server implementations here.

Lenses

One of the things a sophisticated HTTP app has to deal with is taking stuff out and also putting stuff into HTTP messages. When we take parameters out of requests, we also care about validating these values. Http4k comes with a fascinating concept that helps us deal with the stated concerns:

Lenses

.

Basic Definition

Lenses, according to multiple resources, were first used in the Haskell world and are a functional concept that may appear slightly hard to understand. Let me try to describe it in a shallow, understandable manner. Let’s say we have a class

Whole

which comes with different fields

part1

,

part2

, and so on. A lens basically composes a getter and a setter focusing on precisely one part of

Whole

. A

Part1Lens

lens getter would take an instance of

Whole

to return the part it is focused on, i.e.,

part1

. The lens setter, on the other hand, takes a

Whole

along with a value to set the focused part to and then returns a new

Whole

with the updated part. Remember that a lens can be used to both get and set a part of a whole object. Now, let’s learn how this concept helps us with handling HTTP messages.

Lenses in http4k

Following the basic idea of a lens, http4k lenses are bi-directional entities which can be used to either get or set a particular value from/onto an HTTP message. The corresponding API to describe lenses comes in the form of a DSL which also lets us define the requirement (optional vs. mandatory) of the HTTP part we are mounting a lens on. Since HTTP messages are a rather complex container, we can have lenses focusing on different areas of the messages: Query, Header, Path, FormField, Body. Let’s see some examples of how lenses can be created:


// lens focusing on the path variable name
val nameLens = Path.string().of("name")

// lens focusing on a required query parameter city
val requiredQuery = Query.required("city")

// lens focusing on a required and non empty string city
val nonEmptyQuery = Query.nonEmptyString().required("city")

// lens focusing on an optional header Content-Length with type int
val optionalHeader = Header.int().optional("Content-Length")

// lens focusing on text body
val responseBody = Body.string(ContentType.TEXT_PLAIN).toLens()

So far, the API for creating lenses looks more or less straightforward but what about using them on a target? Here’s the pseudo code syntax for
a) Retrieving a value:

<lens>.extract(<target>)

, or

<lens>(<target>)

b) Setting a value:

<lens>.inject(<value>, <target>)

, or

<lens>(<value>, <target>)

Use Lens to Retrieve value from HTTP Request

Reusing the

greet

sample from earlier, let’s modify our code to make use of lenses when retrieving a value:


val nameLens: BiDiLens<Request, String> =
    Query.nonEmptyString().required("name")

val greetHandler: HttpHandler = { req: Request ->
     val name: String = nameLens.extract(req) //or nameLens(req)
     Response(OK).body("hello $name")
}

We create a bidirectional lens focusing on the query part of our message to extract a required and non-empty name from it. Now, if a client happens to call the endpoint without providing a

name

query parameter, the lens automatically returns an error since it was defined as “required” and “nonEmpty”. Please note that, by default, the application exposes much detail to the client announcing the error as

org.http4k.lens.LensFailure: query 'name' must be string

including a detailed stack trace. Rather than that, we want to map all lens errors to HTTP 400 responses which implies that the client provided invalid data. Therefore, http4k offers a

ServerFilters.CatchLensFailure

filter which we can easily activate in our filter chain:


// gzip omitted
val app: HttpHandler = ServerFilters.CatchLensFailure
 .then(requestTimeLogger)
 .then(routing)

Use Lens to Set value in HTTP Request

After looking into extracting values from HTTP messages, how can we use the

nameLens

to set a value in an HTTP request?


val req = Request(GET, "/greet/{name}")
val reqWithName = nameLens.inject("kotlin", req)
// alternatively, http4k offers a with function that can apply multiple lenses at once
val reqWithName = Request(GET, "/greet/{name}").with(
    nameLens of "simon" //, more lenses
)

The example shows how we create an instance of

Request

and inject a value via one or many lenses. We can use the

Lens::inject

function to specify the value we want to set into an arbitrary instance of

Request

. Now that we saw a basic example of a string lens, we want to dig into handling some more advanced JSON content.

JSON handling

We can choose from several JSON implementations, including e.g., the common Gson and Jackson library. I personally prefer Jackson as it comes with a great Kotlin module (Kudos to my friend Jayson Minard 😉). After adding a JSON format module to our application, we can start marshaling objects to and from HTTP messages using lenses. Let’s consider a partially complete REST API that manages persons:


[...]
import org.http4k.format.Jackson.auto

class PersonHandlerProvider(private val service: PersonService) {
    private val personLens: BiDiBodyLens<Person> = Body.auto<Person>().toLens()
    private val personListLens: BiDiBodyLens<List<Person>> = Body.auto<List<Person>>().toLens()

     fun getAllHandler(): HttpHandler = {
             Response(OK).with(
                 personListLens of service.findAll()
             )
        }

     fun postHandler(): HttpHandler = { req ->
             val personToAdd = personLens.extract(req)
             service.add(personToAdd)
             Response(OK)
         }

     //...more
}

In this example, we see a class that provides two handlers representing common actions you would expect from a REST API. The

getAllHandler

fetches all currently stored entities and returns them to the client. We make use of a

BiDiBodyLens<List<Person>>

(BiDirectional) that we created via the

org.http4k.format.Jackson.auto

extension for Jackson. As noted in the http4k documentation, “the auto() method needs to be manually imported as IntelliJ won’t pick it up automatically”. We can use the resulting lens like already shown earlier by providing a value of type

List<Person>

and inject it into an HTTP

Response

as shown in the

getAllHandler

implementation.
The

postHandler

, on the other hand, provides an implementation of an

HttpHandler

, that extracts a

Person

entity from the request and adds it to the storage. Again, we use a lens to extract that JSON entity from the request easily.

This already concludes our sneak peek on lenses. As we saw, lenses are a fantastic tool that lets us extract and inject parts of an HTTP message and also provides simple means of validating those parts. Now, that we have seen the most fundamental concepts of the http4k toolset, let’s consider how we can test such applications.

Testing

Most of the time, when we consider testing applications that sit on top of a web framework, we have to worry about details of that framework which can make testing harder than it should be. Spoiler Alert: This is not quite the case with http4k 🎉

We have already learned that

HttpHandlers

, one of the two core concepts in the http4k toolset, are just regular Kotlin functions mapping requests to responses and even a complete http4k application again is just an

HttpHandler

and thus a callable function. As a result, entire and partial http4k apps can be tested easily and without additional work. Nevertheless, the makers of http4k thought that it would still be helpful to provide some additional modules which support us with testing our applications. One of these modules is

http4k-testing-hamkrest

, which adds a set of Hamkrest matchers, we can use to verify details of message objects more easily.

Http4k Handler Test Example


import com.natpryce.hamkrest.assertion.assertThat
import org.http4k.core.Method
import org.http4k.core.Request
import org.http4k.core.Status
import org.http4k.hamkrest.hasStatus
import org.junit.jupiter.api.Test

class PersonHandlerProviderTest {

    val systemUnderTest = PersonHandlerProvider(PersonService())

    @Test
    fun getAll_handler_can_be_invoked_as_expected(){
        val getAll: HttpHandler = systemUnderTest.getAllHandler()

        val result: Response = getAll(Request(Method.GET, "/some-uri"))

        assertThat(result, hasStatus(Status.OK))
    }
}

This snippet demonstrates a test for the

PersonHandlerProvider

we have worked with earlier already. As shown, it’s pretty straightforward to call an

HttpHandler

with a

Request

object and then use Hamkrest or whatever assertion library you prefer to check the resulting

Response

. Testing

Filter

s, on the other hand, is “harder”. To be honest though, it’s just one tiny thing we need to do on top of what we did with handlers. Filters map one

HttpHandler

into another one by applying some intermediate pre or post-processing. Instead of investigating the mapping between handlers itself, it would be more convenient to again send a

Request

through that filter and look into the resulting

Response

. The good news is: It’s super easy to do just that:

Http4k Filter Test Example


val addExtraHeaderFilter = Filter { next ->
    {
        next(it).header("x-extra-header", "some value")
    }
}

@Test
fun adds_a_special_header() {
    val handler: HttpHandler = addExtraHeaderFilter.then { Response(OK) }

    val response: Response = handler(Request(GET, "/echo"))

    assertThat(response, hasStatus(OK).and(hasHeader("x-extra-header", "some value")))
}

We have a

Filter

called

addExtraHeaderFilter

that adds a custom header to a processed request and then forwards it to the next filter. The goal is to send a simple request through that filter in our test. What we can do, is making the filter a simple

HttpHandler

by adding a dumb

{ Response(OK) }

handler to it via

then

. As a result, we can invoke the newly created handler, now containing our very own filter, and investigate whether the resulting

Response

object contains the new expected header. There we go – both handlers and filters got tested 🙃
To wrap up, I want to say that this was just a quick look at the happy paths of testing http4k apps with mostly familiar tools. It might become necessary to test against the actual running server and verify Responses on a lower level, e.g., comparing the resulting JSON directly. Doing that is also possible and supported via the Approval Testing module. Later in this article, we want to look at the client module of http4k, which again opens up some new possibilities.

Serverless

One of the hottest topics of our time is Serverless computing. You know, that thing where we can run our code on other people’s… servers. One part of it is known as Function as a Service, or FaaS and the most common ones include AWS Lambda, Google Cloud Functions, and Microsoft Azure Functions. The general idea is that these vendors provide a platform where we can deploy our code, and they take care of managing resources and scaling our application on demand. One of the downsides of Serverless is that our functions may be spun down by the platform if it’s not being used until someone wants to use it again, which would require a fresh startup. What does that mean for us? We need to choose target platforms and tools which allow a fast start-up of our application. Spring on the JVM in its classical form, for instance, would probably not be the best tool for that use case. However, as you can image, http4k with its small footprint and super quick start-up times is a great choice. It even comes with native support for AWS Lambda.

I won’t dive much deeper into this topic as part of this article, but I’m planning to write a much more detailed post on what we can do with http4k on a FaaS platform. Stay tuned.

Client as a Function

By now, we have learned how cool http4k is and why it’s a great tool to develop server applications. HTTP Servers don’t make much sense without clients using them, so we want to conclude this article by looking at the other side – Clients as a Function.
The http4k

core

library comes with everything we need to get started with clients. Clients in http4k again are just a special form of an

HttpHandler

, as we can see in this little snippet:


val request = Request(Method.GET, "https://kotlinexpertise.com/sitemap.xml")
val client: HttpHandler = JavaHttpClient()
val response = client(request)

The shown

JavaHttpClient

is the default implementation that comes with the

core

library. If we were to prefer OkHttp, Apache, or Jetty instead, we would find a related module to replace the default. Since we program against interfaces (clients are

HttpHandler

s), it’s not a big deal to swap out implementations at any time. The

core

library obviously comes with several default

Filter

s we can apply to our client which can be found in the

ClientFilters.kt

file that contains stuff like

BasicAuth

,

Gzip

and more stuff you’d expect for a client. The fact that all concepts of http4k servers, including handlers, filters and also lenses, can be reused in http4k clients opens up quite a few possibilities so that it can make much sense to e.g., use the client module to test your servers an vice versa.

Summary and Lookout

I personally learned to appreciate http4k a lot in the last couple of weeks. Once you’ve made yourself comfortable with the basic concepts, it becomes straightforward to develop (which includes testing) server applications quickly. Http4k comes with an incredible list of supported concepts and technologies including OAuth, Swagger, Websockets, XML and many, many more. Its modular nature allows us to add functionality by applying dependencies as needed, and due to its simple base types, it is highly extensible. Http4k is a toolset that allows us to write applications with quick startup times which also makes it a valid alternative when it comes to FaaS and Serverless computing. As if this wasn’t enough, the toolset also includes sophisticated means for writing HTTP clients, which we learned about in the last section. Overall, http4k is a promising technology that you should definitely consider when choosing your next HTTP toolset.

If you want to learn more about Kotlin and its fantastic language features, please have a look at my talk “Diving into advanced language features”.

The post Server as a function with Kotlin – http4k appeared first on Kotlin Expertise Blog.

Continue Reading Server as a function with Kotlin – http4k

End of content

No more pages to load