gRPC + WSGI in one binary?

518 views
Skip to first unread message

zun...@humu.com

unread,
May 31, 2018, 12:29:55 PM5/31/18
to grpc.io
Hi everyone,

I'm spinning up a new gRPC server in Python (3.6), and it would be very useful for me if the same binary could serve some other types of HTTP request as well -- /statusz-type requests as a simple example, but likely other things. (Having a single binary is valuable because then these requests could report on the active state of the server, without requiring that this be synchronized to some storage, multiple deployments, etc) We also already have a well-established stack for implementing WSGI servers in our org.

One approach would be to have the main loop both spin up gRPC and run some WSGI server in a separate thread. (Are there any WSGI servers which are friendly to this kind of thing? Most use multiple processes) But that seems a bit wasteful, since cygrpc already has a really good HTTP server inside it that's polling in a fashion frankly better than most Python-compatible web servers do.

Does anyone know if there is a way to access the underlying HTTP server within cygrpc or even gRPC itself -- essentially, to have HTTP requests which aren't part of some underlying RPC flow passed to a handler function instead of simply being dropped as an error?

(This is very easy with the underlying Stubby code, of course, but I'm not sure how gRPC handles it and source-diving has proven uninformative so far...)

Yonatan

Ken Payson

unread,
May 31, 2018, 1:27:54 PM5/31/18
to zun...@humu.com, grpc.io
This functionality isn't supported or easily exposed in the open source gRPC Python implementation.

I would recommend the approach you suggested and run the WSGI server in a separate thread.



--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/0bc44915-5fed-4abe-babc-6dcab8b9ce91%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Yonatan Zunger

unread,
Jun 1, 2018, 6:57:37 PM6/1/18
to Ken Payson, grpc.io
Question about how people "usually" do this, then: if someone is running a gRPC server on GCE or app engine or the like, how does it answer health checks? Those would be a simple example of a non-RPC HTTP request.

On Thu, May 31, 2018 at 10:27 AM, Ken Payson <kpa...@google.com> wrote:
This functionality isn't supported or easily exposed in the open source gRPC Python implementation.

I would recommend the approach you suggested and run the WSGI server in a separate thread.



On Thu, May 31, 2018 at 9:29 AM <zun...@humu.com> wrote:
Hi everyone,

I'm spinning up a new gRPC server in Python (3.6), and it would be very useful for me if the same binary could serve some other types of HTTP request as well -- /statusz-type requests as a simple example, but likely other things. (Having a single binary is valuable because then these requests could report on the active state of the server, without requiring that this be synchronized to some storage, multiple deployments, etc) We also already have a well-established stack for implementing WSGI servers in our org.

One approach would be to have the main loop both spin up gRPC and run some WSGI server in a separate thread. (Are there any WSGI servers which are friendly to this kind of thing? Most use multiple processes) But that seems a bit wasteful, since cygrpc already has a really good HTTP server inside it that's polling in a fashion frankly better than most Python-compatible web servers do.

Does anyone know if there is a way to access the underlying HTTP server within cygrpc or even gRPC itself -- essentially, to have HTTP requests which aren't part of some underlying RPC flow passed to a handler function instead of simply being dropped as an error?

(This is very easy with the underlying Stubby code, of course, but I'm not sure how gRPC handles it and source-diving has proven uninformative so far...)

Yonatan

--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscribe@googlegroups.com.

Mehrdad Afshari

unread,
Jun 2, 2018, 3:59:18 PM6/2/18
to zun...@humu.com, Ken Payson, grpc.io
On Fri, Jun 1, 2018 at 3:57 PM Yonatan Zunger <zun...@humu.com> wrote:
Question about how people "usually" do this, then: if someone is running a gRPC server on GCE or app engine or the like, how does it answer health checks?

From gRPC Python's standpoint, health checking and reflection services on a gRPC server are exposed as standard gRPC services, not plain HTTP.  I don't know about GCE or App Engine in particular, but I can imagine a proxy would be able to translate between those and plain HTTP if it wants to. 
 

Mehrdad Afshari

unread,
Jun 2, 2018, 4:02:35 PM6/2/18
to zun...@humu.com, Ken Payson, grpc.io
P.S. I know this is tangential to the run-web-server-alongside-gRPC question and does not directly address that problem, but for users who need to serve HTTP under certain paths and also gRPC under the same roof, recent Nginx releases support "grpc_pass" directives that selectively route gRPC paths to a gRPC backend and you can pick and choose what URL gets to which server (be it plain HTTP or gRPC).

al...@prol.etari.at

unread,
Apr 23, 2019, 2:51:40 AM4/23/19
to grpc.io
If anyone is still interested in doing this, I've put together a small WSGI compatible gRPC-Web implementation over here https://github.com/public/grpcWSGI that should live happily alongside other WSGI apps like Django in the same process.

It's compatible with at least 1 other implementation already but there's more work to do.

Lei Wang

unread,
May 4, 2019, 10:33:07 AM5/4/19
to al...@prol.etari.at, grpc.io
I am interested in it.

On Tue, Apr 23, 2019 at 2:51 PM <al...@prol.etari.at> wrote:
>
> If anyone is still interested in doing this, I've put together a small WSGI compatible gRPC-Web implementation over here https://github.com/public/grpcWSGI that should live happily alongside other WSGI apps like Django in the same process.
>
> It's compatible with at least 1 other implementation already but there's more work to do.
>
> --
> You received this message because you are subscribed to the Google Groups "grpc.io" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.
> To post to this group, send email to grp...@googlegroups.com.
> Visit this group at https://groups.google.com/group/grpc-io.
> To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/aa3a5c05-2265-4381-9cec-53dee60294cd%40googlegroups.com.

Lei Wang

unread,
May 4, 2019, 10:33:18 AM5/4/19
to al...@prol.etari.at, grpc.io
Thank you for your effort!
Reply all
Reply to author
Forward
0 new messages