Extract akka-http-model, make akka-http-core depend on it

[ktoso]

Akka HTTP's HTTP model is very much state of the art when it comes to a statically typed HTTP Model. This is confirmed by other projects, such as http4s, using the good ol' Spray model, and we know we improved a lot over the Spray model in Akka HTTP.

By making the model it's own module Play could (and should) use it for their typed headers feature (and later on entire model perhaps). The model should include the parsing things as well.

It's ok that model depends on akka-streams, we like the entities being modeled as streams.

Discussed Play roadmap with @wsargent and this would be a great win for both of the projects we think.

[viktorklang]

:+1:

[ktoso]

Hi @wsargent @gmethvin @schmitch, so I looked into this and we talked it over in the team as well. When looking at what akka-http would actually become we found that it would contain very little classes, mostly just the Http "entry point object" and some server internals (around 20 classes in total, all of it).

We were thinking with @patriknw that we're not sure the split is that important, rationale:

• it would make a lot of sense if splitting (core / model) would allow Play to avoid some additional dependencies... but we don't add any dependencies in akka-http-core – it is just the parsing / model / ~20 server classes.
• it would be tricky, but doable, with regards to splitting up where we get settings from - mostly it's about the parsers which get settings depending on if they're "server" or "client", so it's weird to talk about "server" or "client" in the model module itself, but in practice it makes sense so that's what we have now.

Do you think the split is really needed and would speed up adoption of the model by Play, or not so much (sounded useful, but not that important once you look at it)? We need to decide this very soon, as we're trying to release a stable version as-soon-as-possible.

Have a look at what's inside akka-http-core and let me know, if you strongly feel about the split and it really would contribute to quicker adoption we could do it, but if not we feel it's not enough bang-for-buck. Esp if we'll be considering the akka-http backend more seriously...

Open to suggestions, please comment!

[schmitch]

Somehow I lost the issue...

Actually the first thing I actually wanted to use in play wasn't the model, I actually worked on the Uri Parsing for our netty backend and we looked into scala-uri, however that pulls in spray-json and parboiled which pulls in shapeless, so that means we either need to shim it like akka did it or maybe reuse the akka stuff here.

I actually raised that to the typesafe/lightbend people and I guess they enlarged it since we also have and issue to use typesafe headers which we might can reuse from akka-http.

the problem I guess is that it would look wierd if we have akka-http as a dependency in our netty backend, while we might only need the model classes, even if everything else might be just 20 classes.

Well I also toyed with your HttpEntity since we have one as well https://github.com/playframework/playframework/blob/master/framework/src/play/src/main/scala/play/api/http/HttpEntity.scala (guess we borrowed it earlier) but I guess ours is way way more simpler, and I'm not sure how much it make's sense to use yours instead. The benefits would be:

• less copying (even less than in netty)
• even more backpressure built in

while the negatives would be:

• we don't hide the stuff behind a play package anymore
• users who need to drop to the low level entity might drop to your docs also. But there is only one place where we actually have it in our docs so we might just create a simple Object.apply for that case: https://www.playframework.com/documentation/2.5.x/ScalaStream#Sending-large-amounts-of-data

Well I also made clear that I probably will polish the akka backend for play even more since I think it's valuable and in the future I might even implement play-ws with akka-http, but I'm not sure how the Ligtbend guys want to handle it. Well the akka-http backend still has things we still need to fix: #210 and maybe some smaller other issue's and for the client it still misses a request timeout and might be slower (I never checked if it's slower tough), but everything else could've been done just well with akka-http I guess but I'm not sure how the http model might be reused for play-ws.

I'm also looking at your http2 implementation and maybe I find some stuff useful to even reuse it for the netty backend.

[wsargent]

even implement play-ws with akka-http

@eed3si9n is also interested in this...

[jlprat]

Is this still needed? If so I could give it a try :)

[ktoso]

Hmmm... I suspect it is indeed still interesting however perhaps not a blocker for play anymore so less pressing. The plan is also for akka to provide the http2 backend for play and the Betty one not currently at least so there is less of a urgency to extract the model, as play is expected to depend on akka http core in any case.

[schmitch]

well depending on how play will go and how play 3.0 will look like it might be still interesting as ktoso said. If play keeps netty on 3.0 but want to have a typesafe request model it would be good to have akka-http-model, but I think that's up to @marcospereira or @richdougherty to decide. I mean what would be more interesting would probably be a alternative to netty native transport which will probably attract even the "netty looks better in benchmark"-crowd.

[jlprat]

I was working on this some days ago. I have a really rough WIP module, where maybe too many things were moved, because I was prioritizing compatibility over correctness. I will try to polish it a bit and submit a PR