We (Etsy) are interested in server-side support for PHP in gRPC, as well.
We have two main motivations that I imagine are relatively common. One, our
PHP-based REST+JSON API
has grown an internal pseudo-type system
over the years that is beginning to look like protobuf or thrift and we'd
rather just use a proper serialization format than evolve it. Two, we have
code generation to make developing these clients easier. We see
gRPC+Protobuf as a great possible solution to both issues.
Nicolas -- I understand the reluctance to support PHP servers given that
most folks are using PHP with Apache or nginix. But we would be thrilled to
get started with unary RPC only. Perhaps, as PHP and Apache/nginix evolve
their HTTP/2 support the gRPC PHP server support could evolve, as well.
On Sunday, October 9, 2016 at 8:38:51 AM UTC-4, kon...@beberlei.de wrote:
> 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> wrote:
>>> 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
>>> - 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.
>>> 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
>>>> 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
>>>> 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
>>>> access to the full HTTP/2 stream, which is required to properly server
>>>> 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
>>>> 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?
>>>>> 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
>>>>> 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.
>>> To post to this group, send email to grp...@googlegroups.com.
>>> To view this discussion on the web visit
>>> For more options, visit https://groups.google.com/d/optout.
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to email@example.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit
For more options, visit https://groups.google.com/d/optout.