![]() 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. Note: Some components such as HTTP/2 might have more requirements.And so I decided to write another HTTP Client using Scala. No additional dependencies, JDK 5 (Netty 3.x) or 6 (Netty 4.x) is enough Well-documented Javadoc, user guide and examples.True connectionless datagram socket support (since 3.1).Highly customizable thread model - single thread, one or more thread pools such as SEDA.Based on a flexible and extensible event model which allows clear separation of concerns.Unified API for various transport types - blocking and non-blocking socket.As a result, Netty has succeeded to find a way to achieve ease of development, performance, stability, and flexibility without a compromise. Netty has been designed carefully with the experiences earned from the implementation of a lot of protocols such as FTP, SMTP, HTTP, and various binary and text-based legacy protocols. 'Quick and easy' doesn't mean that a resulting application will suffer from a maintainability or a performance issue. It greatly simplifies and streamlines network programming such as TCP and UDP socket server. Netty is an NIO client server framework which enables quick and easy development of network applications such as protocol servers and clients.
0 Comments
Leave a Reply. |