Play 2.7 Roadmap

Play 2.7 is due in Q2 2018. Here’s a link to the roadmap we’ve come up with: https://docs.google.com/document/d/11sVi1-REAIDFVHvwBrfRt1uXkBzROHQYgmcZNGJtDnA.

If you have anything you plan on contributing to Play in that timeframe that you think is worth mentioning on the roadmap, let me know and I can add it on.

4 Likes

Is this thread specifically for the roadmap, or also questions?

Because I have questions regarding PlayService for minimal applications(What is its intended use case, is it more ideal for ebean projects that don’t have a public facing web interface to worry about?)

And this: Support Java actions without a thread-local Context (How is this going to be migrated? It’s really useful to get URL parameters out of the request() object, which if I recall uses the thread local context, etc…)

1 Like

Well this means that instead of

public Result myAction() {
ctx().request()....
return ok();
}

one would write:

public Result myAction(Request request) {
return ok();
}

as an example, but there is still no clear api for that.
another idea was/is:

public Action myAction() {
request -> ok();
}

That would be pretty cumbersome to migrate, and confusing especially since it would require adding an argument to each controller method, that isn’t actually reflected in the arguments provided in the routes file itself.

I can’t exactly tell how the 2nd example would operate.

In projects I’ve worked on, I mostly use request() as a way of detecting arguments added to individual calls, allowing for more fine-grained control over things like database queries.

A common example is providing start and stop times in the URL parameters. Those can be entirely optional. Making a separate route for no provided times, only start provided, only stop provided or both provided, seems like a bad idea when I can do it with only 1 route. And with this data, I can then dynamically add parameters to the ebean query.

They’re optional dependencies and the decision of adding them is entirely up to the user making the call. They might want a historical view of everything between 2 UNIX timestamps(provide start and stop), or they might say “I want everything of the past X hours”(provide only start).

The concept of a “context” seems logical, as each route being called(each action) is logically its own separate thing that cannot affect the application as a whole.

My main concern is: will I still be able to easily, without changing much of my code, access this data that I will unpredictably need or not?

EDIT: I just remembered optional parameters in the routes file. I probably forgot because I recall demonstrating the mere abilitty of doing request() somewhere.

well in 2.7. it would be just another option to define your routes, you would still be able to use request().

Ah ok, it will just use a different underlying system then?

I also seem to recall, but I’m not certain on this point, that request() contains the (possibly provided) language of the one calling the route, allowing for use of language-separated error messages, with the messages files.

I was just concerned because I recall request() currently being a part of the context and I was worried about losing that. Because it’s just so utterly convenient.

And I assume there will be other ways to keep track of specific data per thread, in order to avoid querying it to the database more than 1 time per route called/action.

PlayService omits sbt-web and twirl, as well as the routes compiler and the custom Play layout. Those things can be added back manually if you need them (by adding SbtTwirl, RoutesCompiler, etc.). It’s designed for situations where you want a minimal Play service, or if you want to manually add sbt plugins as you need them rather than depending on everything. This was a commonly requested feature in the past.

3 Likes

I do recall asking “how do I disable sbt-web” a few times in the past and finding it wasn’t possible. Seems neat and I’ll certainly try it out.

@KoenDG As I understand it, the current proposal is to add an additional Request parameter to your route. So you can use this instead of using the static request() method. It’s the same Request type so the API would be the same.

In any case, the old API should still be usable in 2.7 so you’ll have time to migrate to whatever the new way is.

2 Likes

With the new/current proposal, would you still be able to do things like below in classes other than controllers?

Http.Context.current()

Well, the new way would be to pass the Request to your controller and then explicitly pass it around to where it’s needed. For the other methods that mutate the context like those on Response, you could accomplish the same thing by manipulating the Result.

I’m sure it will still be possible to use Http.Context.current() in 2.7 though. I don’t think we should deprecate any of the existing static methods until we’ve given people a chance to try out the new API.

The main benefit here is things are much more obvious to new users. You no longer need to ask the question “can I use the context here?” because you’re not using thread local state. Everything is passed explicitly.

1 Like

What is actually meant by

gRPC client support

?

Is there any support already in 2.6.x? Where would gRPC be hooked and for what kind of purpose?

Thanks

I think it means more integration with https://github.com/akka/akka-grpc

2 Likes

Exactly. That means that Play could receive gRPC requests. There would also be an easy way for Play to make gRPC requests.

2 Likes

Will there just be a separate gRPC HTTP/2 server running along side the normal HTTP/1.1 server for Play then? Are there any other details for what’s planned on the serving side?

Our plans are to share a single HTTP server, using the Akka HTTP Play server’s HTTP/2 support.

Details will be forthcoming when something is ready to try out, or if you want a lot of details, you can follow progress in the issues and pull requests in https://github.com/akka/akka-grpc.

1 Like

Thanks Tim.

Hi
We are contemplating an upgrade from Java 7 to either 8 or 11, on the assumption 9 and 10 are obsolete by the time we put the upgrade into production - so we are skipping them in favour of the LTS version.

Assuming many others make the same jump (from 7 or 8 to 11), could you add something into the roadmap (or on here in the comments) to clarify the approach to 9, 10 and 11 individually? Or does the existing roadmap infer that “Java 9+” includes 11?

It’s my understanding that 11 removes some items that were deprecated in 9 so I think its not that straightforward … but I am not an expert - do you have a view?

Thanks

Pete

1 Like

Hey @pete.mantell.v1,

The roadmap is now updated to reflect the reality: while Play community had made some effort to ensure everything will run in Java 9 & 10, we are not extensively testing in such versions (for example, our Travis configuration does not include Java 9 & 10) and we haven’t tested at all in Java 11.

The safest path then is to use Java 8 which is widely tested and supported by Play and its dependencies. Of course, you can try to run in Java 9 & 10 and, if something goes wrong, report an issue, but this will be handled with a best-effort approach (pull requests are usually welcome).

Best.

1 Like