Play 3.0 roadmap

[Greg Methvin]

Hi Play devs,

Over the next few months we're working to finalize the roadmap for Play 3.0. Since we'd like to make some big changes in 3.0, I want to make sure the Play developer community is aware of what we're planning and has the opportunity to comment, suggest features, and otherwise contribute to the discussion.

To me, Play 3.0 is about being simpler, more modular, more consistent, and even easier to develop with than before. We want to fix some inconsistencies such as the mismatch between how requests and responses are modeled, and provide more type-safe APIs for headers and storing data on requests. We also want to remove the last bits of global state, so your application is completely self-contained. Some of these things will actually be implemented in some form for 2.6, with the goal of that being the only way in 3.0.

Now I'm interested in hearing what you guys think.

You can find the roadmap document here: https://docs.google.com/document/d/11sVi1-REAIDFVHvwBrfRt1uXkBzROHQYgmcZNGJtDnA

If you're a contributor to Play and would like to collaborate, please email me directly so I can give you access to comment. (Currently I'm limiting to people I know are contributors or active community members, but if you're not sure just ask.)

Cheers,

Greg

--

Greg Methvin

Senior Software Engineer

Lightbend, Inc.

[Dominik Dorn]

When I recently started introducing submodules to my project, I wanted to pull out the submodule specific configuration to a reference.conf 

As there is no way to define an order in which the reference.conf files are loaded (at least I haven't found one), I failed to do this. 

So a way to specify a ordering of reference.conf files would be great.. in an optimal world, the ordering would be the same as I've defined 

the module dependencies in my build.sbt

The PR for providing a Context ( https://github.com/playframework/playframework/pull/6473 ) should be kind of optional.. the methods  look a lot 

like the ServiceCalls in Lagom and from JUG feedback, people find them very ugly.. Instead we should maybe allow people to just add the Context as

a parameter to an action, kind of 

public Result myActionName(Http.Context context, String someId) etc.. 

those are the first two things I've noticed.. If more comes to my mind, I'll post again. 

cheers,

Dominik

--
You received this message because you are subscribed to the Google Groups "Play framework dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-dev+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Dominik Dorn
http://dominikdorn.com | http://twitter.com/domdorn
XING: https://www.xing.com/profile/Dominik_Dorn
LINKEDIN: http://at.linkedin.com/pub/dominik-dorn/66/b42/bb1/

[Viktor Klang]

Hi Dominik,

On Mon, Sep 12, 2016 at 11:49 AM, Dominik Dorn <dom...@dominikdorn.com> wrote:

When I recently started introducing submodules to my project, I wanted to pull out the submodule specific configuration to a reference.conf 

As there is no way to define an order in which the reference.conf files are loaded (at least I haven't found one), I failed to do this. 

If you need order in your reference.conf's it means your overloading things in your reference.conf which is, as you have discovered, not what it is made for. (reference.conf is for providing defaults for a specific library / artifact)

If you want to introduce layering (overrides) you should do that when the config is loaded or using an include directive: https://github.com/typesafehub/config.

In code: overrides withFallback overridden

 

So a way to specify a ordering of reference.conf files would be great.. in an optimal world, the ordering would be the same as I've defined 

the module dependencies in my build.sbt

The PR for providing a Context ( https://github.com/playframework/playframework/pull/6473 ) should be kind of optional.. the methods  look a lot 

like the ServiceCalls in Lagom and from JUG feedback, people find them very ugly.. Instead we should maybe allow people to just add the Context as

a parameter to an action, kind of 

public Result myActionName(Http.Context context, String someId) etc.. 

those are the first two things I've noticed.. If more comes to my mind, I'll post again. 

cheers,

Dominik

On Mon, Sep 12, 2016 at 4:40 AM, Greg Methvin <gr...@lightbend.com> wrote:

Hi Play devs,

Over the next few months we're working to finalize the roadmap for Play 3.0. Since we'd like to make some big changes in 3.0, I want to make sure the Play developer community is aware of what we're planning and has the opportunity to comment, suggest features, and otherwise contribute to the discussion.

To me, Play 3.0 is about being simpler, more modular, more consistent, and even easier to develop with than before. We want to fix some inconsistencies such as the mismatch between how requests and responses are modeled, and provide more type-safe APIs for headers and storing data on requests. We also want to remove the last bits of global state, so your application is completely self-contained. Some of these things will actually be implemented in some form for 2.6, with the goal of that being the only way in 3.0.

Now I'm interested in hearing what you guys think.

You can find the roadmap document here: https://docs.google.com/document/d/11sVi1-REAIDFVHvwBrfRt1uXkBzROHQYgmcZNGJtDnA

If you're a contributor to Play and would like to collaborate, please email me directly so I can give you access to comment. (Currently I'm limiting to people I know are contributors or active community members, but if you're not sure just ask.)

Cheers,

Greg

--

Greg Methvin

Senior Software Engineer

Lightbend, Inc.

--
You received this message because you are subscribed to the Google Groups "Play framework dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Dominik Dorn
http://dominikdorn.com | http://twitter.com/domdorn
XING: https://www.xing.com/profile/Dominik_Dorn
LINKEDIN: http://at.linkedin.com/pub/dominik-dorn/66/b42/bb1/

--
You received this message because you are subscribed to the Google Groups "Play framework dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-dev+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Cheers,

√

——————

Viktor Klang

Deputy CTO

Lightbend, Inc.

[Edgar Twigg]

I love that Play has adopted java.util.function.*, CompletionStage and other Java 8 functional programming API's.

I would like to see further embrace of the Java ecosystem by taking sbt out of the required developer experience, and making Gradle a first class citizen.

[Ben McCann]

Gradle does have some support for Play: https://docs.gradle.org/current/userguide/play_plugin.html

It would be nice to refactor as much common functionality for application reloading as possible into a library that can be used by SBT, Gradle, and Maven since it looks like Maven support is also on the roadmap. This is something I started trying to do earlier by renaming sbt-link to build-link, but I think that we can go further.

-Ben

On Mon, Sep 12, 2016 at 10:05 AM, Edgar Twigg <edgar...@gmail.com> wrote:

I love that Play has adopted java.util.function.*, CompletionStage and other Java 8 functional programming API's.

I would like to see further embrace of the Java ecosystem by taking sbt out of the required developer experience, and making Gradle a first class citizen.

[Greg Methvin]

Embracing the Java ecosystem is a very important goal of Play 3.0. Most Java users don't want to have to learn a bunch of new stuff to get started. I think we've been missing out on a lot of potential users because we're using an unfamiliar build system and many features (routes and twirl) based on Scala. It doesn't feel like a pure Java experience.

Ideally we should make dev mode on Maven, Gradle, and SBT, and most of that logic should go into a library if possible. We probably also want the routes compiler and twirl to work with all those build systems, unless we decided to suggest a more pure-Java alternative for those things.

To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Play framework dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Manuel Bernhardt]

Hi,

two things that come to my mind:

- a "module repository". Play 1 had this concept, inspired from other frameworks such as Rails. With Play 2 there was an attempt to create something more powerful than https://www.playframework.com/documentation/2.5.x/ModuleDirectory but it did never really take off, and so all there is, is this page. What I am talking about here is more than just a webpage, but rather to have a set of CLI tools (sbt commands come to mind) to quickly search and add modules to an existing Play application (and perhaps a nicer webpage). I'm not suggesting that there needs to be a repository that hosts the binaries of the module, but a coherent view on the metadata that would enable CLI tools or IDEs to add existing modules to a project would be helpful as well. I do realise that you can google, find something and add it to the build definition, but that does not bear the same advantages or easy adoption/motivation for re-use of modules out there. And I know there is activator, but activator serves a different purpose.

- CRUD support. Call me old-school, but for many Play projects it would be very useful to be able to bootstrap a generic admin interface à la Django admin module (which includes user support as well). This isn't quite so easy because there's no standard data modelling layer in Play like there is in Django, but I'm thinking that if the framework provided the interfaces required for such a module to thrive, it would be a first step in this direction. I played with some initial thoughts about an "idiomatic CRUD for Play 2" some years ago but unfortunately this never got very far. The proof of concept I'd built back then provided CRUD based on a Play form definition and a mixin (the mixin essentially provided the data storage)

Manuel

To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-dev+unsub...@googlegroups.com.

[Dominik Dorn]

Ok, a few (3) additional ideas:

1)
I think we should enhance the default empty/seed projects to give more structure

for long term development. 

E.g. the current
/app/{controllers,models,views} 
leaves the user clueless on how to organise his code as soon as his project grows a little.

The user is (or at least I was) overwhelmed and confused on where to put code for 

- custom validations (jsr303)

- formatters / data mappers

- guice configuration modules

- actors

- helpers
- filters

- services and their implementations: the predefined packages makes it all too easy to put a lot of logic into the actions in the controllers 

- the Custom ActionCreator and the ErrorHandlers 

2)

As more code is getting async, we should also provide async ways to do
 - Cache handling

 - loading (initialisation) data in the formatters / data mappers / services in a non blocking way.. e.g. a CompletionStage<Void> postConstruct() hook that we add to Guice.  
 - Support/Examples for Akka Typed Actors would be great too, especially for implementing services. This would also solve the above mentioned postConstruct issue. 

3)

A working RequestContext concept would also be great, e.g. allowing to store custom objects in some arbitrary map that correlates with the requestId and allow to retrieve it in other parts of the code while handling the request.. e.g. in my project I create a "correlationId" in a filter at the beginning of the request, load various data, store the data in the cache with the correlationId and a custom identifier for the object and have access helpers that allow me to retrieve this data further down in services just with the correlationId .. its kind of like the Http.Context, just not bound that much to the actual Http.Request but only to the correlation-ID. 
The cache is set to timeout after 30 seconds, so cleanup is also working and if some actors operate a few seconds after the request is handled everything still works.. 

Cheers,
Dominik

[Ben McCann]

The #1 thing I'd love to see added in 3.0 is making serialization/deserialization easier for end users in a way that also makes generating API clients and documentation easier. See https://github.com/playframework/playframework/issues/5317 for more detail on what this means.

-Ben

--

Dominik Dorn
http://dominikdorn.com | http://twitter.com/domdorn
XING: https://www.xing.com/profile/Dominik_Dorn
LINKEDIN: http://at.linkedin.com/pub/dominik-dorn/66/b42/bb1/

--

[raunak]

Would there be OOTB support for docker? and Google Cloud? I'm hoping with version 3, it will be a lot easier to deploy to PAAS.

[Ben McCann]

Play already has built-in support for building Docker images :-)  See here: http://www.scala-sbt.org/sbt-native-packager/formats/docker.html 

On Sat, Oct 8, 2016 at 9:45 AM, raunak <rauna...@gmail.com> wrote:

Would there be OOTB support for docker? and Google Cloud? I'm hoping with version 3, it will be a lot easier to deploy to PAAS.

[Dominik Dorn]

Hmm... we could improve on the docker front by providing optimised base images, where e.g. the basic jars of a framework version are already

provided in the base image, to reduce image size.. e.g. like done in this blog post:
https://joshpadnick.com/2015/11/11/play-framework-docker-circleci-aws-ec2-container-service/

On Sat, Oct 8, 2016 at 9:30 PM, Ben McCann <b...@benmccann.com> wrote:

Play already has built-in support for building Docker images :-)  See here: http://www.scala-sbt.org/sbt-native-packager/formats/docker.html 

On Sat, Oct 8, 2016 at 9:45 AM, raunak <rauna...@gmail.com> wrote:

Would there be OOTB support for docker? and Google Cloud? I'm hoping with version 3, it will be a lot easier to deploy to PAAS.

--
You received this message because you are subscribed to the Google Groups "Play framework dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Play framework dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-dev+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Naftoli Gugenheim]

On Mon, Sep 12, 2016, 1:09 PM Ben McCann <b...@benmccann.com> wrote:

Gradle does have some support for Play: https://docs.gradle.org/current/userguide/play_plugin.html

It would be nice to refactor as much common functionality for application reloading as possible into a library that can be used by SBT, Gradle, and Maven

And CBT too

since it looks like Maven support is also on the roadmap. This is something I started trying to do earlier by renaming sbt-link to build-link, but I think that we can go further.

-Ben

On Mon, Sep 12, 2016 at 10:05 AM, Edgar Twigg <edgar...@gmail.com> wrote:

I love that Play has adopted java.util.function.*, CompletionStage and other Java 8 functional programming API's.

I would like to see further embrace of the Java ecosystem by taking sbt out of the required developer experience, and making Gradle a first class citizen.

--
You received this message because you are subscribed to the Google Groups "Play framework dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Play framework dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-...@googlegroups.com.