I have a Playframework application written in Scala. As you might expect, it’s primary function is to respond to user requests. Typical request flow:
- Parse input and figure out what the user wants us to do
- Gather external resources from db, AWS and so on (relatively slow, async IO calls).
- When IO calls return, execute a series of functions (some of them long-running, some of them not), that do whatever the user has requested, ultimately producing some output.
- Translate output to a HTTP response and return it to to user.
What are the downsides of having ever major function return Future[SomeResult], even when the function doesn’t do long-running work? (In those cases we’d just use Future.successful or equivalent to lift value into a Future.)
One upside is that it makes it easy to compose everything + we get the nice for-comprehension syntactic sugar.
One downside I can see is that the function signatures are “lying” — they suggest the function performs an async operation, but in many cases it does not. This means you’d have to actually look at the function to see what’s going on.
One downside I can see is that the function signatures are “lying”
This is actually fairly significant. Type signatures are a free and guaranteed up to date documentation on your system. Having misrepresentative type signatures then is like having misleading documentation: it harms ramp-up time and future development costs.
In addition putting Future.successful inside your functions actually makes them less composable. Lifting and mapping are core parts of functional programming and are easy to do — reversing a lift when you need to though is not something that’s generally easy to do.
For these reasons I would avoid this approach.
I would suggest not using Future unless it’s needed. Your interface with AWS for example would make sense to have all Future returning methods. The trickiness comes in when you have an interface that may have long-running implementations or may not. In these cases, you can either abstract the return type (i.e. type-class), simply use Future for all, or use a synchronous interface and leave it up to the caller to parallelize. Using Future is pretty easy to implement, but IMO it makes things more difficult to reason about. It also couples you to Scala futures–which have some downsides.
I would recommend looking at free monads because they can help deal with these issues. For example, you can define a free monad AwsOp, and express AWS logic with for comprehensions over a free monad. Then when interpretting the free monad, you can choose to use Future, fs.Task, or whatever side-effect monad you want, or you could interpret the free monad synchronously, or a mixture. The benefit here is that your API is expressed in the free-monad, and its up to the interpreter whether Future is used or not.