-
Notifications
You must be signed in to change notification settings - Fork 65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
0.19 #253
0.19 #253
Conversation
new RhoService[IO] { | ||
// `.pure[IO]` used to require the cats.implicits under test | ||
GET / "route1" |>> { () => Ok("foo".pure[IO]) } | ||
GET / "route1" |>> { () => Ok("foo") } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs to get changed back, otherwise it doesn't properly test for regressions of issue #218
examples/project/build.properties
Outdated
@@ -0,0 +1 @@ | |||
sbt.version=1.1.5 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably set this to 1.2.3
like the main project.
|
||
val routes = | ||
new Routes(businessLayer) | ||
|
||
BlazeBuilder[IO] | ||
.mountService(routes.staticContent combineK routes.dynamicContent, "") | ||
.bindLocal(port) | ||
.serve | ||
.serve.compile.toList.map(_.head) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be better to use head.compile.last
instead of toList
here? No need to build a full list here? (I realize it will likely never emit more than a single Exit code, but if it does, shouldn't we just take the head exit code and stop?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, thanks. We don't want toList
for sure. But I belive compile.drain.as(ExitCode.Success)
is a preferred option for streaming applications inside IOApp
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I saw that in the Http4s docs, wasn't 100% sure thats the right choice either honestly... but I'm ok with using what the http4s docs say.
.bindLocal(port) | ||
.serve | ||
.serve.compile.toList.map(_.head) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as the above comment on head.compile.last
consumes = rr.validMedia.toList.map(_.renderString), | ||
produces = rr.responseEncodings.toList.map(_.renderString), | ||
consumes = rr.validMedia.toList.map(_.toString), | ||
produces = rr.responseEncodings.toList.map(_.toString), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like the old renderString
function was not the same as toString
on a MediaRange. (Possibly not on an responseEncoding
)... toString
's results have a MediaRange
and some parens in the string that 'renderString' did not put there...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm looking at this diff in http4s to see the change: http4s/http4s@f2ca175
audio.midi, | ||
image.gif, | ||
text.html | ||
).map(_.toString) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again, not sure toString
should be the substitute for renderString
on a MediaRange
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems that we have Show
instance for MediaType
. I believe it will be the correct substitution.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe you are correct.
Thank you very much for the feedback, @zarthross. I'm still a little bit puzzled by |
Aha! So, the problem is that indeed |
@@ -14,7 +14,7 @@ class CodecRouterSpec extends Specification { | |||
|
|||
"A CodecRouter in a RhoService" should { | |||
|
|||
val service = new RhoService[IO] { | |||
val routes = new RhoService[IO] { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is still a RhoService
, so i don't know that the rename is appropriate here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But we're immediately converting it to HttpRoutes[IO]
below, so I think all these are justified.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
¯\_(ツ)_/¯
Not really that big of deal. Not a deal breaker for me either way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Removed other similar comments for brevity.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me.
Yeah, sorry about 0.19.0 not being final. I messed up the tagging. Would you like to do a milestone release on this so people can try it? |
I think there is a few more changes @chuwy would like to make before we merge/release, but once he finishes those check boxes, I would like to get this released. I have some projects I would like to get a head start updating before the 0.19.1 release. |
@rossabaker, @zarthross I made some more "service -> routes" renamings to be consistent with core and updated AuthedContext (I believe unsafe Last question I have is whether we should rename |
@@ -7,15 +7,15 @@ import shapeless.HList | |||
import scala.collection.immutable.VectorBuilder | |||
|
|||
/** CompileService which accumulates routes and can build a `HttpService` */ | |||
final class ServiceBuilder[F[_]: Monad] private(internalRoutes: VectorBuilder[RhoRoute.Tpe[F]]) extends CompileService[F, RhoRoute.Tpe[F]] { | |||
final class ServiceBuilder[F[_]: Monad] private(internalRoutes: VectorBuilder[RhoRoute.Tpe[F]]) extends CompileRoutes[F, RhoRoute.Tpe[F]] { | |||
|
|||
/** Turn the accumulated routes into an `HttpService` | |||
* | |||
* @param filter [[RhoMiddleware]] to apply to the collection of routes. | |||
* @return An `HttpService` which can be mounted by http4s servers. | |||
*/ | |||
def toService(filter: RhoMiddleware[F] = identity): HttpRoutes[F] = |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ServiceBuilder
and its toService
function also need a rename.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree, but I think we should handle this along with RhoService
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I agree with the RhoService
rename. It makes sense in context with what http4s is trying to do.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The only worry is that it'll get confusing with RhoRhoute
vs RhoRhoutes
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My worry is similar: we're getting too many "route" in different places that clash with each other and core's. We're ending up with RouteFoo.toRoutes(routes).asRoutes
roughly speaking. But still I believe this is a right choice.
@@ -26,13 +26,22 @@ object MyAuth extends AuthedContext[IO, User] | |||
object MyService extends RhoService[IO] { | |||
import MyAuth._ | |||
|
|||
GET +? param("foo", "bar") >>> auth |>> { (req: Request[IO], foo: String, user: User) => | |||
GET +? param("foo", "bar") >>> auth |>> { (_: Request[IO], foo: String, user: User) => |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can remove the _: Request[IO]
all together here. If Request
isn't the first parameter of the HList
its just not provided.
GET / "private" / 'place |>> { (req: Request[IO], path: String) => | ||
getAuth(req) match { | ||
case Some(user) => Ok(s"${user.name} at $path") | ||
case None => Forbidden(s"not authenticated at $path") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately, if getAuth
returns None
it doesn't mean the user was not authenticated, it means the AuthMiddleware
wasn't applied.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Our authenticated
middleware always returns Some
, but in case where it returns None
(which is still valid) - it will be indistinguishable from not applied middleware. So we have plenty of slightly broken APIs, but this one from my POV is less broken. We just need to mention in comments that AuthMiddleware
always should be applied. Until we come up with best strategy.
@chuwy How many of those checkboxes do you want to complete before this gets merged in? |
@zarthross I think two at least. Should be done in next couple of days. |
I think it would probably be wise to go through with the |
Sure. Totally agree. I meant "all except Bump to final 0.19.1", so this renaming will be included for sure. |
Also, I assume you're fine with |
project/Dependencies.scala
Outdated
@@ -2,7 +2,7 @@ import sbt._ | |||
import Keys._ | |||
|
|||
object Dependencies { | |||
lazy val http4sVersion = "0.18.19" | |||
lazy val http4sVersion = "0.19.0" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The currently version is 0.19.0-M4
, 0.19.0 was mistagged and should be avoided if possible.
Hey @zarthross, sorry for delay. This has been updated to http4s 0.20.0-M1. I also believe I addressed all your feedback and everything I wanted to change. I assume we're not pursuing version-parity with http4s, so I left it as 0.19, not 0.20. If everything is correct, it should be ready for M1. |
Version parity has always been coincidental, but maybe it's nice since it has recently been in lockstep. I guess it might get more complicated when both projects hit 1.0. I don't have a strong opinion there. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm still not comfortable with the way the Auth has played out yet. So lets release this as M1 and I'll work on something before we get to M2.
This is based on #236 and leaves @Igosuki's work almost untouched, but:
TODO
HListToFuncSpec
AuthedContext
AuthedContext
that middleware is mandatoryRhoService
toRhoRoutes
?