Jake Wharton, Android engineer at Square, presented Managing the Reactive World with RxJava at the 2017 Emerging Technologies for the Enterprise (ETE) conference.
A central theme of his presentation was that “unless you can model your entire system synchronously, a single asynchronous source breaks imperative programming.” Wharton explained that imperative programming starts to break down once asynchronous data sources are introduced. The burden of state management is incumbent upon the developer instead of the library that simplifies it. He demonstrated this with a simple example in RxJava. He compared the fundamental sources Observable<T> and Flowable<T>, how to observe those sources, and the operators that may manipulate data or emissions. He concluded with a brief discussion of Java 9 and JEP 266 that introduces a new “Flow” class that encapsulate the interfaces supporting the reactive publish-subscribe framework.
Wharton spoke to InfoQ at ETE about his work at Square and his thoughts on reactive systems, and RxJava, and Kotlin.
InfoQ: How long have you been with Square and what are your current responsibilities?
Jake Wharton: Just passed five years.
I work on the Square Cash application, which is peer-to-peer payments such as sending money to your friends and family. I’m on the Android Mobile team building the Android app which is a relatively small team, three people, compared to the normal Square Register product that most people know. I primarily focus on the architecture, infrastructure, and the libraries that are behind the scenes of the app. The goal is that the other two developers on the team have high velocity in what they're building and how they're developing new screens and features so that we're never stuck or never running into scalability or serialization problems in the app. All the boring bits of the app just always work so that the product itself can always be pushed forward at a really rapid pace.
InfoQ: Most people are familiar with Square through point-of-sale transactions. What other products and/or services does Square offer?
Wharton: Aside from Square Cash, the point-of-sale is basically the tip of the iceberg into all of our products. They're almost all merchant focused and it's anything that has to do with running a business. We're targeting individuals selling something all the way up through proper restaurants and multi-unit businesses using the point-of-sale app and they require a lot more than just an app and being able to swipe a credit card. We have secondary products like employee management, scheduling appointments, and invoice tracking which are complementary to the point-of-sale product as you need to run larger and larger businesses. Because the idea is that you start with Square when you're small, or even just an individual, as your business grows and becomes larger, moves online, moves into a retail location, has multiple retail locations, hires employees, and all those things, we want you to stay within our ecosystem. And because we're offering all those products, we can have a really tight integration across them and trying to present the best experience for managing your business which is otherwise a somewhat boring and mundane task. We can try to do a lot of it for you.
InfoQ: What makes Square unique over other point-of-sale systems?
Wharton: We really embrace the fact that everyone already has a computer in their pocket. For a lot of the things you're doing, we provide the ability to do so on your phone whether that's on the app or the website. A lot of our competitors are, not to say traditional, but the products they built were for larger businesses ten to fifteen years ago. So it's very grounded in an era where everyone was not walking around with a smartphone. You have to pay a lot of money to get their customized hardware and they don't have really engaging, really rich online services that provide a porthole into your business. Square is a very mobile, very data first company trying to push all that stuff out to you whether it's through your iPad that you already have and through hardware that's relatively cheap. To get started taking payments on the phone, we give you a free piece of hardware that costs you nothing. You can start taking payments with basically zero dollars invested. So lowering the barrier of entry, being very mobile first, and being very data first, everything is presented to you online and you can use the things that you're already using every day, your phone, your computer, etc. to be able to control and get insights into your business that way. The other thing is that we went after a market that was traditionally underserved. Banks and these companies that are creating point-of-sale systems want big box stores and the big restaurant chains that give them a good return on their investment. There is this whole market of underserved retailers, whether it's small mom-and-pop shops or individual people selling at farmers markets or craft shows, which is why you go to buy coffee somewhere, you’re likely to see a Square point-of-sales hardware system because that market was cash only.
InfoQ: What are the main differences between RxJava 1.x and RxJava 2
Wharton: The biggest difference between RxJava 1 and RxJava 2 is that now there are two main types of reactive data sources. And the reason there are two is that one allows back pressure and one does not allow back pressure. With RxJava 1, every observable which is the reactive type, exposed back pressure–the ability to be slowed down–but not every source actually honored it. So sometimes when you try and slow a reactive source down, it would throw an exception. In RxJava 2, those types are split so that now you know in the type system that one source has the ability to be slowed down and another one does not. The other big change is that now there is a multi-company effort to standardize the APIs of reactive libraries. That's called “reactive streams” and RxJava 2 natively implements those interfaces and exposes itself as a compliant reactive streams implementation. It's also an opportunity to improve the internal architecture of the library and lower some of the overhead that was found with the original architecture of RxJava 1. So it's faster, it's more compatible, and now you get a lot more guarantees in the type system about how the data sources are going to behave.
InfoQ: Other than Netflix, what other companies are using reactive systems?
Wharton: Netflix is definitely the big one having sponsored the initial RxJava 1 implementation. The main contributors all worked at Netflix and developed the design and implementation of RxJava 1. I know that Lightbend pushes that a lot. They have Akka, which is traditionally thought of as an actor system, but it is also a reactive streams compliant implementation. Beyond that, there are companies listed on the ReactiveX website. In the Android world, it’s definitely taken off a lot for client applications. A lot of major companies building apps nowadays will have RxJava. For the server side, there's already a lot of opinionated libraries in use so you don't see them making the changes rapidly as Android has taken it up.
Netflix is the biggest one. A lot of the open source products and libraries they build are built on top of RxJava. They have a lot of content and a lot of blog posts about how to build systems using this pattern. So that's definitely the biggest one that I’ve seen.
InfoQ: How do you see reactive programming, reactive streams, and RxJava evolving in, say, the next five years?
Wharton: So on the JVM side, now that Java 9 has introduced interfaces compatible with what the reactive streams project created, I think we'll see reactive streams being used a lot more on the server side since it's now part of the JDK. Of course, there has to be implementations that implement the new Flow API, which is what it's called, because currently there are none. It's basically just the interfaces in the JDK - no actual implementations. So we’ll still need libraries like RxJava and Spring’s Project Reactor to implement those. But the fact that it's in the JDK, you'll probably see a lot of these very foundational server libraries like Spring and Netty building their API on top of this so that they can be exposed in this consistent reactive streams manner. Beyond that, for the client side, it's a resource constrained environment on Android and it's likely that RxJava 2 is the best that we can get since these future versions of RxJava and Project Reactor will likely depend on Java 9. For at least the next five years, which is how long it will take for Java 9 to show up on Android and actually be in the wild enough that you can start using it, there probably won't be a whole lot of development other than libraries just adopting RxJava 2.
InfoQ: What would you recommend as a first step for developers to learn reactive programming and RxJava?
Wharton: Now that the new versions of Spring actually implement reactive streams natively, a lot of their documentation has been updated to show the way that you would build servers in a reactive fashion using their APIs. For server developers, that would be a great place to start to see an actual working implementation that you can build and play with. For client and Android developers, there's a ton of content - talks that people have given and open source sample apps that are available to look at. Those are really the best place to get started and, honestly, it's something that really has to click. You can watch as many presentations as you want, you can read as much documentation as you want, until you actually start playing with it and getting a feel for what is actually happening behind the scenes and how these components are interacting. You have this “aha” moment where your brain switches from the traditional imperative way of programming to this reactive, push-based way and you can really start thinking in that new way. But before that, you're really just going to be limited in your understanding without having tried to build and play with these APIs.
There are one or two books that are available. Ben Christensen, who was the original developer at Netflix, did most of the initial RxJava work. He helped out with one that came out a few months ago which has a lot of getting started content that really helps frame how you think about these things in a way that I know a lot of documentation fails to do. That's a good one to read.
InfoQ: What else would you like our readers to know about yourself, your work, and/or any other item that I may have missed?
Wharton: I think one of the most interesting things that seems to be coming is the more prevalent use of Kotlin which actually ties in really well with reactive programming because it allows you to model whether or not a value will ever be null which is something that obviously occurs very frequently. But it also has a lot of language primitives that work really well with RxJava, one example being that it allows us sealed class hierarchies, which are basically an abstract class, and then multiple implementations of the class where no one can implement additional subclasses. This is important because it allows you to model some types where you can have, say, an event coming from your user interface that's either a button click or, say, the user pressing “Enter” on the keyboard. Those can both be subclasses of the same type, and Kotlin’s language allows you to not only define this in a very terse syntax, but also provides you a very convenient when operator which is similar to switch in Java. But unlike switch, you don't have to have a default case because the compiler can prove that you're already handling those two events and there will be no other events that subclass that type. It will also do things like a smart cast so when you're in the case block for each of these events, it automatically casts the event to that type. So when you're building reactive streams in any application where everything has to flow through one pipe, you tend to use a single type and then subclasses to represent different bits of data. Having the language gets you back both syntactically in defining the types but also syntactically when pulling the types out of your own next callback is a really big benefit when mixing both Kotlin, the language, and RxJava or any reactive library together.
InfoQ: It seems like Kotlin has been gaining a lot of momentum lately.
Wharton: It's another case of Android mobile development very rapidly jumping into a new technology, similar to what we experienced with RxJava. And now it's getting a little bit more mature, you're seeing it more in server side development and libraries that are out there which, for whatever reason, tend to take a bit more time to adopt these newer languages and new libraries. So it's nice to see it gaining a lot more traction plus they're very focused on making it extremely compatible and have extremely good tooling which is what a lot of the other alternative JVM languages have been missing in the past.
Editor’s Note
Michael Redlich has been an active participant in ETE since 2008 as an attendee, a speaker, and more recently, as a member of the ETE Steering Committee since 2013.