Posts

I’d like to share an approach for integrating SwaggerUI into Scala projects, using http4s as example. With webjars available you don’t need to copy its complete code into your project, you’ll need just a small piece of it along with 2 dependencies to your build.sbt file - one with SwaggerUI code, and another - webjar ulitity library: libraryDependencies ++= { "org.webjars" % "webjars-locator" % "0.34", "org.webjars" % "swagger-ui" % "3.17.3" } Now we need to customize index.

If you want to get FS2 is a streaming library for Scala which offers more lightweight and more “functional” alternative to Akka Streams. However, as it’s relatively young it either misses some functionality, or has it available in non-obvious way and lacks appropriate documentation. One such example is retrieving data from callback-based API which expects an interface with callbacks for next element, stream end and stream failure - like Subscriber from Reactive Streams Initiative.

I’d like to share some experience from serverless pet project - photo gallery. The idea was to be able to browse family photos backed up to Amazon S3 storage service. They should not be publically available - only authenticated users must be able to browse. When browsing the photos they must be resized to screen size in order to avoid excessive traffic, resized photos must be cached for subsequent requests.

Nowdays RESTful APIs are usually considered to be the only reasonable way for communication between back-end and front-and, and default approach for communicating between separate back-end services. Lot of people consider RPC (remote procedure call) as a curse word. “It’s not RESTful”, “This is RPC” is often used as an ultimate reason why certain API should be discarded, and another designed instead. I used that grounding quite a bit as well, but such reasoning has a cargo cult smell.

Suppose we need to mock such service and verify that doSomething is called exactly once, and then no interaction happens with the service: class SomeService { def doSomething(from: Int = 0, to: Int = 10): Unit = { //... implementation ... } //... other methods ... } A common approach to do it: val serviceMock = Mockito.mock(classOf[SomeService]) //run tested code which invokes this: serviceMock.doSomething() Mockito.verify(serviceMock).search(0, 10) Mockito.verifyNoMoreInteractions(serviceMock) But here’s surprise: it fails with such error message:

Recently I was trying to do some cleanup of shared DB after the tests (with ScalaTest) of Play application using afterAll method of BeforeAndAfterAll trait. DB credentials were contained in Play’s config files so cleanup code relied on running play application. But when trying to run the test I’ve got an exception: java.lang.RuntimeException: There is no started application Looks like application was shut down before afterAll gets started. Turns out that traits inclusion order matters here.

I came to conclusion that even in fully-Scala projects it’s better to define enums using Java. Even third-party libraries that have support for Scala enums suffer from the fact that in runtime all Scala enums have the same type. So if you get some enum value - you have no way to tell to which enum type does it belong. Let me show you how bad it can be with json4s.

As Play JSON library uses implicits in order to know how to serialize/deserialize some object the type of that object has to be known at compile time. This makes serializing/deserializing generic classes not that straightforward - even if you know at compile time type which is substituted in generic class type parameter, you need to provide somehow reads/writes for each such type, not just for single generic class. The trick is to use def instead of val.

I’d like to share my experience on testing versions compatibility with sbt. The system which had to be tested consists of server (Play application) and a client - library that exposes server functionality to other apps. Not all apps that use client library may be updated fast enough with new version of server, so before deploying new server version we must check that client versions which are in use currently keep working.

Parsing may be a challenging task. And it’s amazing how Scala Parser Combinators make it doable for regular human beings. You can easily describe how to parse simple things like identifier, string constant or argument list, and then combine these simple parsers into more comples ones. I’d like to describe here step-by-step how to get that brilliant library working for you. No deep theory or specific features, just bare minimum to get started with typical tasks.