-
Notifications
You must be signed in to change notification settings - Fork 3
Add doc on deployment #52
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
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,68 @@ | ||
| # Deployment | ||
|
|
||
| After building a Connect service, you still need to deploy it to production. This guide covers how to | ||
| use a Python application server to run a service. | ||
|
|
||
| ## Application Servers | ||
|
|
||
| Connect services are standard ASGI or WSGI applications that can be run with an off-the-shelf Python | ||
| application server. Generally, any experience in running a Python application can be applied to running | ||
| Connect as-is. | ||
|
|
||
| ### HTTP/1.1 | ||
|
|
||
| Connect only requires HTTP/2 for bidirectional streaming RPCs - the vast majority of services can be run | ||
| using HTTP/1.1 without issue. Two servers have long been in use with HTTP/1.1 and have a proven track | ||
| record. If you are unsure what server to use, it is generally a safe bet to use one of them: | ||
|
|
||
| - [gunicorn](http://www.gunicorn.org/) for WSGI applications | ||
| - [uvicorn](https://uvicorn.dev/) for ASGI applications | ||
|
|
||
| ### HTTP/2 | ||
|
|
||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not sure and forgot about daphne. Should we mention daphne as well?
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Unfortunately Daphne's http2 support doesn't work with bidi so I think it's confusing to add to this list. And without it, I think uvicorn is a better choice so left it out.
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Unfortunately Daphne's http2 support doesn't work with bidi so I think it's confusing to add to this list. And without it, I think uvicorn is a better choice so left it out.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks, I see. |
||
| If your service uses bidirectional or otherwise want to use HTTP/2, the above servers will not work. | ||
| HTTP/2 support in the Python ecosystem is still relatively young - servers known to support HTTP/2 | ||
| with bidirectional streaming are: | ||
|
|
||
| - [granian](https://github.com/emmett-framework/granian) | ||
| - [hypercorn](https://hypercorn.readthedocs.io/en/latest/) | ||
| - [pyvoy](https://github.com/curioswitch/pyvoy) | ||
|
Comment on lines
+26
to
+29
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'd love to improve https://github.com/i2y/tsuno so it can be on this list someday! (just a comment) |
||
|
|
||
| Connect has an extensive test suite to verify compatibility of connect-python with the Connect protocol. | ||
| Unfortunately, we are only able to reliably pass the suite with pyvoy, with other servers occasionally | ||
| having hung requests or stream ordering issues. pyvoy was built with connect-python in mind but is | ||
| very new and needs more time with real-world applications to verify stability. | ||
|
|
||
| Keep the above in mind when picking an HTTP/2 server and let us know how it goes if you give any a try. | ||
| When in doubt, if you do not use bidirectional streaming, we recommend one of the HTTP/1.1 servers. | ||
|
|
||
| ## CORS | ||
|
|
||
| Connect services are standard ASGI and WSGI applications so any CORS middleware can be used to | ||
| enable it. | ||
|
Comment on lines
+41
to
+42
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We should probably provide a CORS interceptor, so that we don't give the false impression that users need to use Starlette for CORS support.
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think it's ok to add an interceptor but also feel it's an HTTP concern rather than RPC and could be best left to other libraries. I changed to using asgi-cors to stress this is about using off-the-shelf middleware, not starlette's routing. What do you think? |
||
|
|
||
| For example, with an ASGI application using the [asgi-cors](https://pypi.org/project/asgi-cors/) | ||
| middleware: | ||
|
|
||
| ```python | ||
| from asgi_cors import asgi_cors | ||
|
|
||
| from greet.v1.greet_connect import GreetServiceASGIApplication | ||
| from server import Greeter | ||
|
|
||
| app = GreetServiceASGIApplication(Greeter()) | ||
|
|
||
| # app is a standard ASGI application - any middleware works as-is | ||
| app = asgi_cors( | ||
| app, | ||
| hosts=["https://acme.com"], | ||
| # POST is used for all APIs except for idempotent unary RPCs that may support GET | ||
| methods=["GET", "POST"], | ||
| headers=[ | ||
| "content-type", | ||
| "connect-protocol-version", | ||
| "connect-timeout-ms", | ||
| "x-user-agent", | ||
| ], | ||
| ) | ||
| ``` | ||
Uh oh!
There was an error while loading. Please reload this page.
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.
maybe
https://is better?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 guess they'll be in trouble when Chrome requires it - they don't seem to support https...
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.
When I commented, I thought it connected via https, but it seems I was mistaken. sorry...