On Thursday, April 21, 2016 at 7:24:35 AM UTC+2, Nicolas Noble wrote: > > The other languages (Ruby, Node.js, Python, C#, ...) don't have that > issue, because they all have frameworks that are working properly from the > command line. Right now, in order to run a gRPC python server, you can > properly start a python daemon with your code in there. Node has everything > built in for running servers without any front end. Ruby has been doing > this natively as well for a long time. > > Unless somebody shows us otherwise, only PHP doesn't have any proper > support to run a naked daemon. All the options that we've seen or that > people have shown to us are toys or prototypes that aren't suitable for > production usage. Basically, I'm challenging your "it is increasingly > common to write standalone and daemonized PHP processes" and ask for proper > examples and documentation that aren't flagged with warning labels such as > "DO NOT USE FOR PRODUCTION". >
I think the right solution here could be to provide gRPC as a SAPI, that means as a standalone binary "php-grpc server.php" much like "php-fpm", it would start a HTTP/2 webserver and upon receiving the requests, create individual PHP requests to server.php maybe with appropriate context variables in $_SERVER/$_POST. This would keep the sharded nothing PHP principle while allowing the C based gRPC server to handle the long-livedness and streaming. But this might be to complex for the benefit. A workaround could be to write a simple Go based proxy that accepts requests over gRPC/HTTP2 and sends them out to a php-fpm based backend using a Go fastcgi client library. > > On Wed, Apr 20, 2016 at 7:55 PM, <rokcl...@gmail.com <javascript:>> wrote: > >> Nicholas, >> >> I'm also very interested in finding a way to make this work. I do >> recognize the challenges you've outlined below as well as the fact that the >> PHP CLI server isn't suitable for production use. How do the other >> language integrations for gRPC handle this? I would think that Python >> would suffer from the same sort of issues with its SAPIs (mod_wsgi, etc). >> Or does gRPC only support naked Python processes as well? >> >> Looking at this example >> https://github.com/grpc/grpc/blob/release-0_13/examples/python/route_guide/route_guide_server.py >> >> - PHP is capable of performing the same type of socket listening operations >> going on under the hood here. It is increasingly common to write >> standalone and daemonized PHP processes like this one. Whether or not PHP >> will natively support HTTP/2 features is of course another question. >> >> Thanks, >> >> Brian >> >> On Wednesday, January 27, 2016 at 9:14:54 PM UTC-5, Nicolas Noble wrote: >>> >>> There are several problems with the idea of a gRPC server in PHP, and we >>> have no plans for that. >>> >>> Basically, the only way it would work, is if you run PHP "naked", >>> without its typical nginx or apache frontend. You can't serve a long-lived >>> streaming RPC from a PHP page using typical settings. The page will timeout >>> very quickly. You could theoretically restrict yourselves to server unary >>> RPCs only, or have an arbitrary duration on "streaming" RPCs, but that >>> wouldn't be "gRPC" anymore. And even then, there's no proper HTTP/2 support >>> in PHP at the moment. With the typical model of having a frontend that'll >>> forward the requests to PHP processes spawned on the fly, you wouldn't have >>> access to the full HTTP/2 stream, which is required to properly server gRPC >>> requests. >>> >>> For more on that, I invite you to research how to serve websockets from >>> PHP. Probably all of the solutions you'll find will be by running a naked >>> PHP process, without Apache. That isn't the typical way people want to use >>> PHP. So a gRPC server in PHP would be fairly useless as it'd require you to >>> run it in a very atypical deployment environment. >>> >>> On Wed, Jan 27, 2016 at 2:23 PM, <stephen...@bigcommerce.com> wrote: >>> >>>> Hey all— >>>> >>>> It appears as of right now you can only create CLIENTS in PHP, but not >>>> servers. I was wondering what the technical blockers behind this were and >>>> if it's on the roadmap for a future release? >>>> >>>> Thanks! >>>> >>>> -- >>>> 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. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/grpc-io/412dccb6-836e-4486-ab19-34701bec0562%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/grpc-io/412dccb6-836e-4486-ab19-34701bec0562%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >> 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 <javascript:>. >> To post to this group, send email to grp...@googlegroups.com >> <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/grpc-io/954a4480-dc8f-42c6-ab68-44d884634e37%40googlegroups.com >> >> <https://groups.google.com/d/msgid/grpc-io/954a4480-dc8f-42c6-ab68-44d884634e37%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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+unsubscr...@googlegroups.com. To post to this group, send email to grpc-io@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/36b6ae54-b943-46db-99b2-f4e923d3057b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
