![]() Looks good on paper, BUT: macros are not the most stable part of the Scala compiler (as we’ll see in a second) and it will slow down your compilation by A LOT (at one point my project took 12 minutes to compile). ![]() The rest is magically taken care of by Scala macros generating implicit instances of Encoder and Decoder objects. In the simplest scenario all you need to do is provide one import where you want to use en-/decoding: Circe is boasting fully automatic derivation for encoding/decoding your domain model ( case classes and case objects) into/from JSON. That’s when I discovered circe, which seemed to have a very active community behind it, has numerous Q&As on StackOverflow and even comes with its own gitter chat channel. However, in order to reduce the amount of boilerplate required for working with JSON I decided to look for alternatives. If you want to go with spray-json, the good news is that it comes with out-of-the-box support by Akka HTTP. I used spray-json in the past, however the amount of boilerplate required to make it work was not ideal. Again, plenty of alternatives out there and I have to say I haven’t tried most of them. So here is our next challenge: picking a JSON library. We don’t want to bother users of our client library with low-level details of the HTTP communication, right? This means we need to be able to abstract away the JSON wire format into a more robust Scala ADT model based on case classes and case objects. My only piece of advice here for anyone who is starting a new project that requires HTTP client capabilities, don’t waste your time experimenting with different Scala libraries and just pick the one that works, for me it is undoubtfully Akka HTTP. Long story short, eventually I had to abandon dispatch and went back to using Akka HTTP, which was at least mature enough, but more importantly, has the largest community behind it and is being actively maintained. ‘Hello World’ use cases are working fine out of the box, however as soon as you start to require more advanced functionality be prepared to roll up your sleeves and spend countless hours trying to fix basic stuff using limited resources available on StackOverflow and others. This is, unfortunately, quite often a common theme among Scala libraries that either don’t come from Lightbend itself or have a quality label of Typelevel attached to it. But it turned out to be overly complicated and I didn’t want to spend a lot of time ‘hacking in’ basic HTTP functionality when I had a real task at hand. It’s not that I didn’t try to make it work. So far so good! It did indeed work fine for basic GET/PUT/PATCH/POST requests, but as soon as I had to do some more or less advanced stuff with it like processing responses with chunked transfer encoding I hit a road block. It seemed like a solid choice, was being praised as one of the most mature HTTP client libraries written entirely in Scala, is both easy to get started with and has a beautiful idiomatic Scala API. After a quick ‘google’ I found a few alternatives and decided to first give dispatch a try. After all, I didn’t really need any of the server-side functionality, which seems to be the main focus of Akka HTTP, with client capabilities being treated more or less as a stepchild. Initially, I was a bit hesitant to bring in Akka HTTP into my project. However, it is not maintained now and users are directed to migrate to Akka HTTP which is an official rewrite of spray. I used spray in the past and was more or less happy with it. Unfortunately, my conclusion after spending quite some time researching for alternatives in this space is that most libraries are immature, or are not maintained any more, or both. However, as I’ve learned from my almost 4 years experience coding in Scala, this is not always easy. But as a Scala developer, one is always trying to find a good ‘idiomatic’ Scala library first before resorting to other options. And certainly, Scala - being a JVM language - can make use of any of those. There is no shortage of good options for Java, like the de-facto standard Apache HTTP Client or its async sibling, Async HTTP Client, HTTP Client from Google and many other solid choices. You can have a look at the API spec if you want to learn more about specific protocol but here we want to focus on getting the right tools to get the job done.įirst, we need an HTTP client library that we can use with Scala. In my particular use case I wanted to develop a type-safe HTTP client library for consuming Oanda REST API v20. In this post I’ll try to make the experience of writing a HTTP client library in Scala a little less painful so you don’t have to start from scratch. As with so many things in the Scala world, picking your libraries can be the hardest part. Sounds easy? Sure, if you know where to start. ![]() And so I decided to write another HTTP Client using Scala. ![]()
0 Comments
Leave a Reply. |