scala Lightbend 3 23 16

[Music] all right so Gregor's just stepped out for a bit but in the meantime I'm will sergeant I'm from like Bend we used to be type safe where we're still type safe but we're no longer type safe if you get my meaning and we just finished working on play 2.5 play 2.5 is actually a lot of a lot of what we do for play is actually set up the internals and do a lot of work so that everybody who uses play itself doesn't have to and so part of what we did for play what we try to do for play whenever we are migrating whenever we are adding new features is we try to make sure that everything happens in lockstep fashion so whenever we're doing any kind of work to upgrade features or try to change if one place to the other we don't simply delete things if we can possibly help it we actually deprecated them in the release of going from play 2.3 to play 2.4 each one of these is a major releases play has the same version scheme as Scala does so it's actually a pop major minor not release major major minor patch and which confuses a lot of people you'd be surprised when the people who'd be like you you broke this or you deprecated this and it's only a minor release but the goal is basically every single time that we change something and we delete something we give warning we say that this is deprecated we provide people with a migration guide we give them step-by-step instructions on how to get from A to B and then once we're satisfied that everybody is is cool and everybody knows the direction that we're going in then we start removing old code and that's where we actually get to play 3.0 played 3.0 it's where we actually start saying okay we are going to start deleting things out of the system and play 2.4 was actually a big step for us we learned a lot of things mostly we learned a lot of things that we could do better in terms of documentation and in terms of changing and managing people's expectations because we are moving to dependency injection and so with play 2.5 we really want to get your feedback on this we want to see what works what doesn't what's going to what's going to be clear to people and we really have put a lot of work in to make this as smooth experience as possible okay so hands up hands up everybody who's what would play all right cool who hasn't worked play who would like to work with play okay all right so we probably don't need this but slide quite so much but just running over the top play is full stack a synchronous non-blocking web application framework you know what most of these term means but the biggest one is that play is a framework it makes assumptions and it says all right we're going to start off doing everything for you if you want to change anything we will let you do this but we will let you change this one thing without having to change everything else it's not a library it's not something where you have to put together all of the pieces and rearrange them in exactly the right order play does all of the work for you and hopefully I set it up in such a way that you only really need to change one thing or you know a couple of things in order to get it working the way that you would just like so place philosophy is to do the right thing and to do it simply to not make it complicated to do the thing that actually works that actually will scale that actually will let you grow your system from one machine to five machines to a hundred machines to maybe even a thousand machines it doesn't it's it's equally important for play to actually be opinionated about the things that does and things that it doesn't do play is stateless by default it doesn't try to store State inside of the server play is unopp Enya nated about its persistence management framework it doesn't try to tell you what kind of database you should use it doesn't try to tell you if you should use a database at all it doesn't try to tell you whether you should use JavaScript at all for that matter it has an asset pipeline so you can use JavaScript and CSS and everything else should you choose need it but it says whatever you choose to use is up to you we will make sure that we support you within that framework and then of course Play has to be reactive we have to be able to fail gracefully we have to be able to work in a way that makes systems resilient under load and be able to transfer to one to another so if you have like 50 play servers and one goes down we have to be able to make sure that the load is evenly distributed across everything else so what's new in play to note 5 the biggest thing is we have a cast reims we have 20% performance improvement so we've made things faster we have better documentation and better templates so that we have explained everything internally that's going on and we have also set things up for play 3.0 we've set up a reduction in global state so we don't use singleton objects very much but where we do we are slowly minimizing that we have this thing called play dock current where you can point to a current application from absolutely anywhere we are trying to minimize our use of that and squeeze it down more now that we have jdk 1.8 and we can actually use functional paradigms with java we have started taking advantage of that we started taking advantage of completion stage and we started taking advantage of the more concurrent utilities that are available in 1.5 and then finally we we've just done a number of things internally to set up the run way for us so when we have 2.6 we can hit the ground running not having to do a lot of rework under the hood okay so Greg do you want to say CAC extreme so that work okay okay me okay so yeah another thing that we have the probably the major improvement we have we added in play 2.5 is August dreams so it's an imitation of reactive streams which is basically just a way to do streaming with back pressure in the JVM and it has a lot of alcohol extremes in particular has a lot of abstractions that allow you to model data flows you there's a abstraction called graph stage that allows you to kind of very easily model all your inputs and outputs it takes a little bit of time to understand this API is but it also has simpler API is that just you know allow you to connect sources and syncs together at a very intuitive way and it's more imperative which makes it a little bit easier to use than the entities that we were using before which is kind of not as easy to use if you're new to functional programming and you didn't understand some games so we still support it or at ease but we it we do it through an adapter and will probably break that under a separate library in the future and the fact that we have vodka streams is what allows us to do a lot of the new java api that we added and will can do his demo okay sure so this is actually a demo that we set up earlier because the local hosts it's really it's a really high-resolution Vega how's that didn't everyone see that okay and all this does is it sets up a clock that sends the current date and time from the system and you can see if I scroll all the way up let's increase the resolution yeah does this increase okay that that is a remarkable Retina display right there let's do this place and then let's change the preferences all right so this actually is a sample play application we have a lot of actor templates activator templates which are available online and this one is something that you can actually download from github and this just shows you when you're using Scala you can pull an event source flow you can say I've got a string and I can say send this out through Scala as an event stream here through a single action this is one line and the internals here is just sending out a date every hundred milliseconds to update it and you can do this in Scala or you can do this in Java just the same way and the API is almost exactly the same so doing streaming through akka doing series streaming through play using a cue streams is actually very simple and very easy to do all you need to do is get an event source here get a route your streaming the clock you've got an event listener coming through and that's that's all you need to do in order to be able to do event streams but be able to do event a server-side events here okay in addition we have upgraded infrastructure which repeatedly said and part of that is because we're using net e 2.4 this is a huge change underneath the hood it gets us closer to http 2 and the underlying binary interfaces but also we are using async HTTP client 2 on the other end which is also faster and has more features we have the upgraded documentation and migration guide as previously said you can actually do this oops you can actually use activate a new example app and then to us type play scarlet intro and then that takes you to the application page which now has links it now has all other documentation in here it now has comments for absolutely everything that you might possibly need and then we have a search box up here that actually allows you to type anything in and see the integrated text as well so if you don't have a clear idea of what the documentation is telling you then any any errors can actually be seen in the source code and you can actually go in and you can just edit the page and then submit that as a patch request as well so we're trying to set things up so that the documentation is a self improving phenomenon anytime you see something in the documentation isn't there or should work better you can just go in edit it submit it as a pull request and then we will take it and we will pass it in okay so probably the biggest thing that we changed in or they were changing over time and play is removing global State and the problem with global State is it just makes it harder for you to test your application because you have to make sure that state is set up it makes it harder to define different implementations of the same interface and swap those out for different environments it makes your code less modular make it harder for you to tell like what your code depends on so if you want to break it out of different modules it's much harder so we're trying to make it so that people are kind of set up for building state lists or like applications that don't have that that global statement so we've also removed plugins which it was kind of a the source of a lot of bugs because when you initialize to plug-in you normally use some global states somewhere and you have to make sure that your plugins are instantiated in the right order and now everything is just components with dependency that if you want to do stuff at the beginning of an application you do the initialization you just do that in your component in the constructor and then you can add hooks to play shuts down to do whatever you need to do as well so that's that was a really big improvement and we're gonna keep doing that and by 3 todo we're probably not gonna have any global stated all those sets ago so I know this is a scala meetup but this is the Java API is we're actually one of the major things that we did in play 2.5 and now you can pretty much do anything in Java that you could do in Scala before and you know for you guys this is useful because you know a lot more people are going to be able to use skål and used to seeing api's and easily switch over to the Scala API is there's a lot more play users who are using the same back-end as you know the job in Scala backends and play or you know share a lot of the same code so you know you just it just makes the play community better and much bigger and it's easier for you to switch between the two api's oh there's a notebook again sure the good old computing days let's see yeah all right oh now no it's it's asking if we want to optimize for crafter on that that's fine that's that's just uh just minimize it okay this is the screen I can hear the inception sound already okay okay there we go so okay so what's coming in play 2.6 and 3 dead oh no obviously like I discussed before we're gonna remove as much global state as possible freedo will not have any global state at all and that makes a lot of cool things possible like being able to run multiple apps or multiple tests in the same JVM and currently we're also going to be adding a the feature to tell you to tag requests so if you're in a filter and you want to add some information to the requests of a you could use it in a template or something else that's contextual that's specific to that request one place we would use it in play internally is for like the CSRF filter to add the token and a bunch of other initiative that's specific to that request and that's where that state belongs it doesn't belong in global states of where you call some global method it belongs in like with the actual request where acha acha HTTP already has typesafe headers so we're probably going to integrate something like that into play as well so that when you add a header value you're not having to worry about dealing with strongly-typed things you're just able to say you know here are the possible values of this header and make sure that you know it's you have the correct value for it we are moving stuff like juice and some of the other modules into separate into separate modules so that you don't have to you know you don't have to depend on juice you would just add juice and separate module and then we're also going to have other types of dependency injection frameworks you know that you could add as a module and you don't have to have this kind of bloat of extra dependencies and we're gonna have caching for WS so cache-control support so you can actually cache the requests if you've made multiple requests to the same endpoint you can you can save that that data so you're not having a lot those transfer a lot of data and of course HTTP to of support and nettie 4.1 is doing HTTP too so hopefully by the time we released three don't know they'll have a final release and we can and we can use that and you know implement the dbgap guys yeah so yeah yeah so we have a number of questions for the audience which is how are you using play right now a using play on the server side by using it on the client side what works for you what could work better and play or is a particular sticking point and what features do you look at play and think it really should have this but it actually doesn't right now that is what do you think players actually consider it I think as a gap in a system right now so if anyone has any feedback or any questions about play internally alright yes good sir and it's hard to pass conflict information from yeah that that is actually thank you that is actually a problem with execution contexts is that if you're actually passing information between the two of them it's very easy to invent thread-local so yeah we we do have some subtype execution contexts where you can actually pass in some state and you can actually pass some state out again but we don't really have a formalized way of extending that that is something that we I have seen blog posts on that for example but that is not something which Plake currently does that is plays play tries to be essentially stateless and being able to pass things around between different threads is something that usually happens between akka so your if you if you have something you actually need to pull in and out of state etc then you would have like accurate actors passing messages to each other and then you would just be able to reference them inside of that so I'm not sure if that answers your question necessarily first about threads versus having actors because actors so usually we keep state so I don't know if that yeah that that would be you'd have an actor and you would send that actor various messages to pass it through a finite state machine so that as I got those messages its state was continually updated and then finally you can query it to spit back out the finished state when it was done so you would have you would have a short-lived actor for the duration of the request however I cannot request but that the duration of that statistic you would actually create a short-lived actor that would exist only until you'd finished accumulating that state so okay yes that that is something that we have discussed but we don't have any formal clients for it that is something where we would you know welcome help and any code contributions but it's not something we'd necessarily have the bandwidth to be able to take on ourselves yes sorry sorry the question okay I don't know my speakers the question was there is a JavaScript there is a Scala j/s plugin for SBT but is there plans to do something more formal and more native in terms of the integration between Scala Jas and play did I have the question right okay good all right okay yes that's a good point and actually that that didn't that is something that did change but that actually changed technically in play 2.4 not 2.5 and that sorry the question the the question was isn't routing very crude and the answer is yes that's that's fine no the routing was always when routing was first implemented it was a straight rails passed through it from the baser and so it didn't even take account of anything that rail subsequently did like the the rest resources or the namespaces or anything else so when you look at play now there's actually something called the CR deep the Cir D which is the string interpolation yes string interpolation router and that what that does is it provides a DSL which allows you to break down a path and query parameters out of a string and be able to extract that and not only do you have like you know optional query parameters and optional route parameters but you can actually have things like ID path directive finders and so forth so you can actually bind them directly to your domain objects internally and that allows you to write a complete play application inside of 35 lines because a great post by a guy called Lloyd Mehta I believe like I think is blog post is slim 8 you can also find it yeah if you go to the play 2.5 tutorials page we have revamped the tutorials page so that everything is organized and there is a set of new blog posts stating like how you can do complex routing and be able to use players a REST API I think well I only remember is his Twitter handle which is lloyd mehta and the the the website is slim eight I believe but don't don't quote me on that you'll find it in the tutorials page that's about halfway down this and great new into actually let's demo this oh yes go I just got this working today so I'm inordinately proud of it I'm gonna search for it yes let's do that alright if we can do it without breaking the website okay okay all right so now if you go to the Play documentation there is this big search box here and if you type tutorials and you type rest api all right so here's rest api sees third-party tutorials he has played to up for building a simple REST API and this is actually it's not that one it's a minimal play Lloyd channeis a guy and he shows this is a complete play application in thirty eight lines right here so anytime somebody tells you that play is too bulky and too heavyweight and you can't just write a simple Sinatra style play application show them this page because you can do things in play that are very simple and very streamlined there's no need for you to necessarily go through all of the rigmarole right and we're eventually breaking out a lot of the stuff inside play into different modules so you don't necessarily need to depend on the entirety of everything that we yeah you don't need WS you don't need cash everything is modules that you can include or exclude as you want right yes uh-uh wait repeat the question yes so you're asking about type sick types of headers in 2.6 what would they look like honestly we I haven't given a whole lot of thought to it yet but akka HTTP has a fairly good implementation of type safe headers if you take a look at what they've done so it it very likely might look like that where you know essentially although you know the values are kind of made into case classes or into some kind of type safe value um I think what's so hot on that I think some work I mean we've done there definitely is some work that to be done on the documentation we've improved some of the things in the Java forums I don't know if the Scala forum stuff has been touched yeah a little while I mean that there is actually there was a complete reimplementation of the forms API that that's actually called validation it said something that Gillian Tony worked on yeah but that actually turned out to be too much to actually consume inside of a single instead of a single release and so we we have been putting it off until we can properly document it and and release that as well so yeah now we know that form forms is one of these sticky UI places where you have to take user input and you have to do something useful with it and unfortunately it's kind of like you know doom UI you think it's simple and you think that putting together templates are simple right up until the time that you actually start dealing with user requirements and then it's all just horribly complicated in spaghetti code that being said there are a variety of useful templates there's actually a very useful introduction course actually called ICS which goes over how to create some of the software actually wait let's do this let's use the phone this actually should be in the tutorials as well I believe so the forms page here we go example form multiple checkboxes and selection UX friendly conditional formatting so this this also goes into some of the play example forms and how to do complex form handling inside of play as well okay real good yes yes I mean SBT is actually that there is an SBT sub-project oh dear okay yeah so the the SBT the question was is there a standard way to do SBT standard SBT sub-projects and this is actually something which the the documentation does tell you how to do it but but the the way to actually do it involves creating a common area and then being able to pass everything through that so if you look listening your application in several parts here we go sharing common variables in code and then you have different sub projects under this and that's that's basically a lot of what happens from here is building off a play it's building off of SBT I'm sorry and so SBT multi project builds goes into a lot more depth in terms of various different ways to do it unfortunately there isn't a standard way to do it because there is SVT and SBT gives you the flexibility to be able to do it any way you want so if you have a working sub project the best thing to do is look at some of the SBT sample projects and look at some of the place on whole projects I've actually got a couple of them linked again from the tutorials page and then just be able to reference that in particular there's one called play slick 3-0 and place like 3-0 has several different modules which isolate slick and fly ways and some other code from play so you can actually load them independently and then call out to them so that should work yes yes yes yeah yeah no um that that is a good question and okay I will repeat okay the question was what options are there for authentication and authorization in play and this isn't something that play handles itself officially I mean there is a security to authenticate it but it's very minimal what what most people end up using if they have any kind of front-end at all is silhouette if they have a scholar API or play authenticate if they have a Java API so there's actually two different authorizing with an authentication plug-ins for play the silhouette and there's play authenticate and those are both updated 42.5 I believe and on top of that there's also an authorization plug-in called deadbolt which has also been upgraded recently and in addition to that there's also various different Jason token things that plug into that plugin Scala so the the as far as you're concerned you're talking about authorization and authentication as a REST API for play that is JWT JSON web tokens and something called the new security stack which is you know you've got Fido and then you've got JWT you've got signed authenticated tokens and you have all of that sitting on top of a TLS 1.2 stack etc etc so that that is something that play doesn't provide for itself play provides you with the plugins to be able to do JSON web tokens on top of that but you know you're right in that the documentation doesn't necessarily tell you if you're going to do this then do that right yeah and I think that 42.6 in the future we want to provide do make a better integration in the documentation with with modules allow actual external module authors to register their modules and kind of show that they're updated and provide descriptions of their there and all kinds of stuff like that but it's not something that we like authentication a lot of this stuff we saw the thing we want to support directly because there's just so many different ways of doing it it's hard for us to say okay we're gonna build an API ourselves to do every single way of doing authentication yes yeah um there are a couple different ways to do it wait oh sorry you're asking how do you handle lifecycle events like on startup on stop so right now it really it really depends on what you're doing the best solution depends on like what kind of initialization you're doing if you're if you're initializing something specific to some component like you have a database component and that needs to do some initialization on startup a lot of times you can just do that in your actual class in the constructor of your in your class you can do the initialization and then you can inject an application lifecycle instance and use that to add a stop hook so that when your app your app stops it'll call your stop hook before binding fails well if the binding fails for your component then you your application won't even start if the binding is that well I mean if you're using juice or you some other dependency injection framework if there's if the dependencies aren't satisfied then it won't it won't create the injector so you can't it shouldn't it shouldn't start at all no you can tell the compile time maybe yeah or or you know or you can use them pile time dependency injection and you'll know at compile time but if the bindings aren't satisfied then it won't you can't create won't created in small baby I mean I guess I don't know exactly we're asking but if you want to initialize something regardless of whether the binding fails you can create [Music] right Oh okay so if you if so if something you mean not not you mean not the binding if something in the initialization is it's something just throws an exception randomly how do you actually catch that and deal with it in the initialization phase yeah yeah in that case you actually have like a two-phase initialization you bring up the things in binding that you know aren't going to fail and then once you actually brought up all the things that you know to actually get a running system you bring up all the things that you know are going to flake out and throw exceptions on you because they're terrible crap code that has bugs in them you you you bring those up like yourself like once you've actually finished the binding once you've actually started the application then you call out to you know try flaky application then and just keep trying it until it actually works and handle that post binding yeah well in another thing I mean the other thing you do if you want complete control over how your applications initialize you just override the application loader and that and then you can just you can create the application via juice or whatever way you want actually and then after you've you've instantiated your application do whatever initialization you need so that that gives you as much control as you need thank you [Music]