-
-
Notifications
You must be signed in to change notification settings - Fork 250
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
Update zio-http to RC4 & Play to 3.0.0 #1968
Conversation
@ghostdogpr would it be possible to merge #1967 prior to this one? I'd like to try out those changes without migrating all the zio-http code 😅 |
ZHttpAdapter.makeHttpService(HttpInterpreter(interpreter)) | ||
} | ||
Routes( | ||
Method.ANY / "api" / "graphql" -> ZHttpAdapter.makeHttpService(HttpInterpreter(interpreter)).toHandler |
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.
Should we return a Handler
if we have to do toHandler
to use it?
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 thing about it is that I'm unsure whether there might be other methods of composition that I haven't figured out yet. E.g., the HttpApp is also convertible to Routes
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 never going to use it as Routes
because it doesn't have any path in it, right?
Maybe make makeHttpService
return a Handler
for the most common case but keep a variant that returns the HttpApp
?
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 after thinking a bit about it you're right, I don't think there's much of a reason returning an HttpApp. I changed it to return Handlers instead
# Conflicts: # .circleci/config.yml # build.sbt
@ghostdogpr tapir 1.8.5 is out and it adds the ability to provide custom WS config for zio-http. Have a look at the changes in ZHttpAdapter and let me know what you think. I also added the play update in this PR otherwise CI would fail since tapir 1.8.5 is not compatible with play 2.x |
# Conflicts: # .circleci/config.yml # build.sbt
PR updated to migrate the QuickAdapter to RC4 |
.collectHttp[Request] { case _ -> Root / "api" / "graphql" => | ||
ZHttpAdapter.makeHttpService(HttpInterpreter(interpreter)) | ||
} | ||
Routes( |
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 directly related but how about using the quick adapter for federation examples (or any examples that are not about a specific adapter).
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.
Ah good point. I'll change it
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.
So much cleaner now 😃
Tapir has a new release with support for zio-http RC3. This required very few changes in the adapter, but had to change the examples to work with the new routes structure