Yes, I’m Sadek Drobi, I work on the Play Framework, I worked at Zenexity, it’s a company of web applications. So basically we have clients, we take parts of their systems and we do them, we do everything from interface to infrastructure and basically we make front end and back end and all of that, and actually we created the Play Framework, I started working on the Play Framework from version 1, 1.something and then we started from scratch working on Play 2 which was released last march, so I’m co-creator of the Play Framework and that’s pretty it, I’m still working on that.
The context that we work is the Zenexity in real world web apps, and we have some set of problems and we try to solve them with tools that we got, because we are not a software publisher, we don’t do software, what we do is use existing tools to do apps for our clients. The problem is that we starting like using what existed by then, and we start like adding some stuff, some tools on top of them to make it like the experience easier for the developers, something like you know hot-reload some other tools around it for doing web service call and these kind of things that make sense. And then we starting things like: “Wow, this makes sense, let’s try to package it” and we started packaging it for our clients and for our users and then we thought like: “Ok, we can do a framework” that has all these kind of nice properties.
We package that together with what we call it Reactive Architecture, and that was Play 1, and once we’ve got Play 1 we worked more and more on Play 1 and then we noticed that there are other kind of requirements that we could address easily with Play 1, because the whole web programming changed a lot in the last few years and it started from I want this single box where I have my web app and my database and they are talking to each other on the same machine mostly to a very distributed kind of system with much more requirements of like communicating with outside world, being like rest API’s, existing SAAS services or whatever else. And then we notice, ok we try to extend Play 1 as much as we can but we notice like is not going to, I mean it’s very hard to extend it more of that. And we are saying like: “Ok, let’s try to think what was the problem from the beginning, how can we address these kind of problems”.
We thought like we need to be able to manipulate data in an easy way, so data manipulation was a focus for us, and we need a language that will allow data manipulation and that is where we are starting like experimenting with Scala, and so we saw the Scala because is functional, it has the required concepts to be able to manipulate data in an easy way, in a very simple way. So that is the data manipulation thing which is very important to Play, but also the architecture that we needed really to built complete reactively, because you are talking to all these services and you need to have some kind of non-blocking architecture, and that is also another requirement, and together with other things and we thought like: “Ok we can do this”.
And we started working on Play 2 and the Beta was like three months after, a lot of people were interested in our work and by the release candidates there were already some services that deploying it in production including The Guardian, so we keep working on it and in March we released it and we are really happy, I mean there is still working on improving things but it seems like we hit the spot there, it made sense to make these kind of changes and introduce a new version of the framework.
3. The Guardian was one of your clients?
The client was in one of our clients but they used the framework even before we released officially. It was a release candidate, so they are following us in master and the release candidate and then the official release, I guess the story as I remember it, but it was like very encouraging to see a lot of big companies are interested in the framework and you already using it, and today actually a lot of big companies do use it, we have a lot of users including LinkedIn, including The Guardian and some others that I can’t mention their names for now, but probably I guess quite so many.
Absolutely, one of these requirements that we see in Web Application Development nowadays, there are two things: first I want to be able to talk to a lot of services even for one user request, I want to call several services to grab data for that user and get it back, that is the first thing, and we need data manipulation and reactiveness. There is another thing, today if you open your Twitter for instance and you wait a few seconds you will find like it’s continually updating, new tweets are coming and the service will be pushing that into your browser, so the browser should be pushing this notification showing this on the interface. The same happens if you are opening you Facebook page, if you observe it, you see it’s moving on everywhere, because there are new things happening, new activities, new messages, new photos, and it’s kind of realtime, the website is not as static as it used to be in the 90’s, now is really moving a lot and you need a new paradigm, a programming model, so you need an architecture and a programming model, two things are important: the architecture that can support this kind of life as streaming and the programming model.
And why we talk about the programming model, because for instance in Java when we talk about objects, we can reference them, pass them in parameters, we can deal with them in a very natural way, simple. When we talk about functions in Functional Programming Language, same thing, they are First Class Citizens and you can reference them, put them in values and pass them in parameters. Well you need to be able to reason about streams in the same way, which means like I would like to reference this stream and I would like to be able to adapt to it, and maybe to consume it in some way. So you need a new programming model to be able to talk about these things about streams in a simple manner. And this is extremely important, in Play we wanted like to address the realtime and the streaming kind of requirements. We didn’t want just to give you the possibility of doing if by just giving you maybe channel.push() and that will help you, will allow you to do that, and channel.on message and where you receive on a call back, we think that there is too primitive, I mean at some point you will get to do more complex stuff.
For a business application you’ll have to filter things, secure streams, dispatching them differently on different users, all of this kind of stuff, you need to be able to express it in a declarative simple way, so if the problem is simple, which is like I’m dispatching to all clients, it’s seems simple the problem, you don’t really want to have way too much complexity for doing that because the problem is simple, the solution should be simple, and you should be talking the same kind of vocabulary, I’m dispatching the stream, and since you are talking about stream as First Class Citizen, then you can be able to talk about these things, and that is what we integrate in the 2 Play, it’s a programming model for dealing with streams based on something called Iteratee IO. So you can imagine it, in Java they were something like this, there is something like this, and that is very strange because you feel like we are moving backward instead of advancing, because Java had input and output streams, so input and output stream is a way to abstract over something that it’s looks like a stream, an input stream where you can read stuff and output stream where you can write stuff.
And it’s kind of good, I mean you know I was designing a long time ago, and it’s still an abstraction over streams. This is good, now going backwards and starting talking about channel.push and channel.message, I guess that is doing the wrong thing, and I guess frameworks should be thinking about how we can we address the streaming kind of capacities. Of course now input and output streams, they have some problems because they are blocking and that is what we wanted, we wanted something like input and output streams but non-blocking, and that is where we got to Iteratees, so basically when you do realtime web, what you want to do is to talk about streams in a simple way to be able to manipulate being filtering, dispatching, securing streams, all of these things but using an API, any programming model. We think that you absolutely need this kind of programming model, whatever it is, might not be our programming model, this is one example of a programming model that can help that, but there are a lot of others, you can even improve the input-output stream API’s to have, make it more reactive and non-blocking, but that is ok, you need the programming model, the point is that you need this kind of programming model.
5. For the developer you can do it in a declarative way?
You can use it like you use a list of things, you say list.filter and this is how you filter, well the stream, you say the same thing except that it will happening progressively, you don’t have the result now, whenever the chunk comes it will be filtered, whenever something comes it will be mapped, so the same kind of semantics for lists that you have today in a lot of languages including Functional Programming Languages where you apply the same kind of API to streams and it will be declarative, that is what we have today and that is possible to do when you talk about streams as something that you embrace in your programming model.
6. Ok, I know you are working on a new version of Play, what is going on there?
The 2.0 was putting the foundation, the server, the core and what is around it. Then we got to release a lot of work and then we are happy that it got there, and then we got a lot of experience working with some clients about how to make Play even better in several things, so one of them is Modularity. Today when we release Play, it was already kind of modular but what we want is, you have some type of project that you want to start with Play and you don’t want to get all kind of dependencies, if you don’t care about them. Imagine you are doing for instance a Scala Play, you don’t want all the dependencies of Java, you can add them to your project later on, but you don’t want to download the whole thing. The same thing if you are using for instance Java but you are not using Hibernate or you are not using other things, then you just don’t want this and we allow you to do that, there is very few by default and then it’s kind of you can integrate wherever dependencies, you can integrate your legacy system into Play, well that is we worked a lot on this kind of modularity issues, that is one of the very important thing because we know enterprise, you have legacy, you have other things to care about and the framework should be helping you to do that. And today in what you are working on, the Play core is really small, there is almost like just the core server and some API’s and it stops there. Everything around is just dependencies.
Of course by default you don’t see this, because you get the default dependencies but you can partition it, break it into pieces and get just what you need. So that was the dependency part that we really worked on.
Now the other thing, we notice that also working with our clients we need some way, so today web API’s that are a lot about exchanging some data, and exchanging mostly JSON data. Now if I’m exposing a rest API with JSON, so someone will send me a JSON object, JSON message, and then at the server what I will do, the first thing I will do is look at it and see if matches the JSON that I’m expecting, and if it doesn’t then I might want to send a bad request status, to respond with a bad request, this is not the right JSON, and even if I want to validate that JSON and see what errors should that I can report more to that user, to the end user what is wrong with his message.
Now that is why we went to the JSON API, that was already kind of nice and we worked a lot on making it much better and it has now validation, it has some kind of transformation API that helps you deal with JSON, because mostly you grab a data store that it will storing documents, you will be storing JSON inside, let’s say MongoDB, and now you get this JSON, what you want is only validate it but also to remove certain parts because you don’t want to insert them into your database, you want to make sure that what you are inserting is what you want to really insert and we added these API’s so that you can prune something, modify, have another object and push it into your datastore, or get from your data store, remove some maybe sensitive data from your JSON, transform the other part, work it so that it matches the API because you might not want to store exactly what is sent in your data store, you want to just remodule it in some way, and that is also what we added in the JSON API. We put a lot of efforts into getting this JSON API to respond to real world requirements, this kind of data manipulations.
This is another thing and also at Zenexity we work on a MongoDB driver, ReactiveMongo where it allows you to do a lot of things well integrated into this architecture, which is like saving big files into Mongo and the reactive way, progressively pushing in the Mongo, downloading from Mongo, to connected to Collections, to Life capped Collection, all of these things. We wanted to focus on data because we think that data is important today, the most important thing in modern web applications is about data, so that is another focus, and there is a lot of improvement for API, for the core, we did a lot of improvements as well into the framework. So yes, that is what I can remember from, also there are small things we did into API, you can write several routes files instead of one because people wanted like, they didn’t want centralize, but that are other features that we added into framework.
7. What is the timing for 2.1?
I don’t know where this interview will be out, but we are trying to get a release candidate for like very soon, in the weeks to come. A release candidate and then starting with there we are going to see how it goes but we want really, we are almost ready. The big thing that we did with 2.1 is for what we schedule as 2.1 version is integrate the Scala Futures, because we had our own future API, we called “Promises”, and then now there is this standard API that is included in Scala and we wanted to integrate that so that any other API that uses this, then it’s very easy to integrate with Play, and that was essential, that was one of the big things also that we did for the 2.1 version.
8. How much collaboration is there with Typesafe?
It’s a kind of weird model we have with Typesafe, because you know, Zenexity, my company, we created the framework but then we know, I mean we created it out of experience, we needed some this kind of tool, but then at some point we have this framework and what can we do about it, of course we can use it, but then you need the software publisher that can commercialize it, provide some support for company, because this is important. Of course it’s an open-source project but then people want some guarantees, they want to learn about the framework, some courses, all of these things, so we were looking for a modern stack, modern software stack, that we like to integrate Play into and we find that Typesafe wasn’t there so we started like Typesafe together with the company, and we worked with them to have this company Typesafe that includes not only Play with Scala and Akka, which are really modern components for talking about Concurrency and modern problems. And we are happy with this kind of collaboration.
So now Play framework is a Typesafe thing, we still work so we still lead the design, me and Guillaume, and some other people at Zenexity, they do contribute but there is Peter Hausel at Typesafe that is doing the project management, other people add Typesafe that also are working full time on the framework. So this is the kind of collaboration model, so the team is Typesafe, we still lead the design and the main strategy of the framework, but the project is a Typesafe project. And we are really happy because that is what we wanted, we wanted like to find Play home where it can grow, where it can be maintained, where we can be relieved to put it in there while using it for our own client, because by the end of the day what we are interested in is using it for our own clients, and we didn’t want to change our model and this was the way to do it.
9. Off camera we talked about Java 8 and so what can you tell us about that?
It’s very interesting what is going on, I mean it took some time but that is all right, so Play for us first of all, maybe I didn’t mentioned, but Play is a Scala and Java framework, so the core is developed in Scala because it was for us much easier to write it in Scala because the language is very powerful and allows us to do a lot of things more easily but then we also provide a native Java API, so when we work on something, we work for the Java side and for the Scala side and we are very serious at both at the same level, because ourselves, we have some clients that only use the Java API. Some of the questions that people ask me about, and I will get back to the question because it’s interesting, some people ask me: “Ok, you’ve got this powerful API for the streams in Scala”, in Java you got this channel.push and channel.message and that is kind of: “Can you have the same model?”.
With Java Prior to 8 is very hard, we can introduce it but then you have a lot of anonymous classes, a lot of syntax for expressing one single simple thing, and I guess is not like Idiomatic Java anyway, so you will get people lost, we prefer to focus on what is possible to do with Java right now but we are waiting also, we knew that Java 8 is coming and we could integrate this kind of things. With Java 8 you get a system that looks like Traits, you get a system like Lambda.
Michael: So Lambda’s are Traits, Scala is Traits…
Traits are the extension default of the implementation things, and Lambda’s are functions kind of, so what we could do now and we already start working on it and things what we can do it, and we can do very similar interface, maybe not as powerful because Scala is still a more powerful language but we can do something really good with what we have in Java 8, so we can provide this some kind of programming model that is really interesting for dealing with streams with what we got in Java 8. Basically people think that we want only to push Scala or what we want is a programming model. We have an idea and we want to implement it, and since Java 8 is providing all these Lambda and Traits, extension methods, so we can really implement the same thing using these methods and get the kind of very close experience for the Java developers, and that is really good because there are a lot of people that are using Java and they are not counting on moving to Scala.
Of course, Scala is more powerful at some points, but maybe you don’t need that much power or to me if you ask me, I say: “I think Scala is good, is very good” and I would replace it, but some people don’t think and then of course you have to take into a consideration, all the learning curve, you have big teams. We have a lot of clients that are on Java and that provides a lot of opportunities and there is one important thing as well is that when you have this API’s integrated in Java, anyway you’ll be able to do some things, but then at some points you might need something else, so if makes sense for you then you will be moving to Scala and that provides some kind of progressive learning curve, not moving in Scala right away but start trying integrating Lambda, some functional stuff, the streams and then you see, I need a little bit more than that, I can not do it with Java, well I could move to Scala, is easy now for me, and it should not be about the religion, so not be Java or Scala.
That is what happens with CSharp, in CSharp they integrated some novelties some years ago, functions and some other stuff and then some people, it was ok for them, it was ok for their needs, and they stay there, some people found out that they need more and they move for instance to FSharp, to other languages, and that is what I’m seeing happening here in the Java world, so it’s not kind of like a competition, I don’t see it at all as a competition between Scala and Java quite the opposite, it will make much more developers aware of what they can do with functional programming and having function in these kind of things, and then they can do their own decisions, if they don’t need more power or they want to stay in the Java world, and in both cases it’s all right for us, we want just to give the possibility to do these kind of things.
Michael: Ok, well thank you for coming by today!
Thank you!