Servers in PHP?

[stephen...@bigcommerce.com]

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!

[Nicolas Noble]

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.

--
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.
For more options, visit https://groups.google.com/d/optout.

[shiv...@gmail.com]

Nicolas:

Not sure why you are making apache as a requirement. The way you run the node server one could run the php-cli to serve requests. Please point me to what I may have missed.

Shiv

[Nicolas Noble]

This is basically what I am saying at the end of my response: while you could indeed use php-cli to serve requests and create a fully-featured server, this isn't a viable setup at all, and it would only be a proof of concept with no production value.

To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/3df76fa6-dd68-45cc-9548-c91b357d9d74%40googlegroups.com.

[Shiv Haris]

Here is something you may find interesting, and this is quite OK these days to run a webserver with phpcli (similiar to node):

http://php.net/manual/en/features.commandline.webserver.php

--

-Shiv

[Michael Lumish]

 The top of that documentation page says "Warning: This web server was designed to aid application development. It may also be useful for testing purposes or for application demonstrations that are run in controlled environments. It is not intended to be a full-featured web server. It should not be used on a public network."

To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CAJhP0xBGECXFCB-Cui3r-ZKivj%3D4eUu1bv9qRRgBzO7G6jGy-A%40mail.gmail.com.

[rokcl...@gmail.com]

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

[Nicolas Noble]

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".

To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/954a4480-dc8f-42c6-ab68-44d884634e37%40googlegroups.com.

[be...@yelp.com]

Something like ReactPHP may be a way around the typical PHP issues?

http://reactphp.org/

[Nicolas Noble]

Which requires to run the server as a naked php process, which is still not a scalable, nor recommended solution by the php community itself, and is almost never supported by php web hosting services.

To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/c73bca19-479e-47ae-8166-e2a78f389a55%40googlegroups.com.

[be...@yelp.com]

PHP web hosts are an irrelevant part of the discussion when we're talking about gRPC. We're already a sophisticated enterprise running our own processes by that metric.

[Brian Morton]

I generally agree with Ben on this one.  Most orgs/individuals looking to run gRPC wouldn't be doing so on shared LAMP hosting.  I'm going to dig into ReactPHP and see if it will support the necessary HTTP/2 features.

[Nicolas Noble]

For all intend and purposes, ReactPHP doesn't offer anything more than what the C core of gRPC already does. The core handles async I/O, as well as HTTP/2 servicing. All of the async I/O could be handled there, on dedicated threads. The synchronous model of the gRPC server means that a single thread can bear the workload for processing the requests. Meaning that supporting running PHP as a gRPC server is bound on writing code around what we already have, without any third party dependency needed. However, that requires naked PHP servicing, and from our point of view, the official PHP server support always hung around the fact we have never seen any significant demand for PHP beside LAMP hosting, and we've repeatedly asked for tangible proof of the contrary before committing resources to support that model.

To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CA%2BK14zE9xuUnkT_HW_MfaVBJW39zeZ31aZieY%3DXHDtRv5c4Eug%40mail.gmail.com.

[kon...@beberlei.de]

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. 

[Gregg Donovan]

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 API clients in Objective-C, Android, PHP, and JavaScript with homegrown 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.

[Varun Talwar]

Team, we would like to understand problems and use cases for PHP server in more depth and figure out a plan here. We would like to come up with a reasonable solution which is not a one-off. We are happy to help and review contribution in grpc-ecosystem to make this happen. I have added a meeting next week Thursday at 10:30 AM PDT and included Greg, Brian, Ben, Stephen. If you want to get added to this meeting or if the time doent't work for you, let me know. 

Thanks

To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscribe@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/bbf2d3a8-a456-46cb-bcac-7966e4d4cf40%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Varun Talwar | Product Manager | varun...@google.com | 415-341-7352

[Shiv Haris]

Please add me. Thanks.

Shiv

Varun Talwar | Product Manager | varuntalwar@google.com | 415-341-7352

--
You received this message because you are subscribed to a topic in the Google Groups "grpc.io" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/grpc-io/F3IyYaI_6S0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to grpc-io+unsubscribe@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/CAHbcPLkhaccac9p%2BFXFkMG5r%2B0ed1JHDhGUHA%2BN3xRns8femoQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

-Shiv

[Gregg Donovan]

Thanks, Varun, much appreciated -- Etsy will dial in.

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/bbf2d3a8-a456-46cb-bcac-7966e4d4cf40%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[zack....@bigcommerce.com]

We've developed PHP server support in the form of a gRPC to FastCGI (PHP-FPM) bridge. If there's interest, we'd definitely like to open source it and get some more members of the community involved. 

Please feel free to reach out to me directly or through the mailing list: zack....@bigcommerce.com. 

[lukasz....@lemondemon.pl]

That's wonderful news!
You should definitely open source it. gRPC server for PHP is a must - in the age of microservices not all PHP processes are running on shared hosting with LAMP stack.

Let me add to this discussion that at least from 10 years I haven't develop any code for old fashion shared hosting (and I'm working with PHP around 15yrs).

[Brian Morton]

Hi Zack,

My team at DVIDS is definitely interested. We will help with the project if you choose to open source it.

Thanks,

Brian

[Gregg Donovan]

Zack,

We at Etsy would be very interested, as well. We'd also be happy to test it out and contribute back if you choose to open source it.

Gregg

[scott molinari]

I'd also be very interested in your PHP server solution. A php microservice platform could be one of those things, which would help PHP lose that "red headed step child of a language" rap it gets. :-)

Scott

[zack....@bigcommerce.com]

Just a quick update -- we've cleared the open sourcing with the rest of the team and are working to extract some proprietary bits. 

Will get something up ASAP to be evaluated for admission into the gRPC ecosystem. 

[scott molinari]

Nice! :-)

Scott

[Jayant Kolhe]

Hi Zack,

Please let us know if you have run into any bumps.. We would love to see it come up on gRPC ecosystem since a lot of users have expressed interest in it..

Thanks,

 - Jayant

--

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.

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/0c67e504-d046-45d4-ae75-74cba27e5df6%40googlegroups.com.

[Dmitriy M]

Any progress on this? We are planned(ing) to implement something similar, but common open-source implementation would be easier to support and use.

BTW what language did you use for the proxy implementation?

суббота, 10 декабря 2016 г., 1:14:14 UTC+3 пользователь zack....@bigcommerce.com написал:

[scott molinari]

Not sure if this will help, but this might be of use.

https://github.com/amphp/aerys

It supports HTTP/2.

Scott

[kovacs.t...@gmail.com]

Hi Zack,

is there any news about your implementation?

On Saturday, November 19, 2016 at 12:14:16 AM UTC+1, zack....@bigcommerce.com wrote:

[ivans...@gmail.com]

Hello guys,

I've just released "GRPC everywhere". It's NodeJS service which receives GRPC request and passes them to PHP (or something else) by FastCGI (or something else). It's kinda nginx or proxy. You can specify path to proto file and fpm address in config and it works.

Be warned: not all GRPC specification implemented and only FastCGI connector for PHP is present. But I used it in several internal projects in production more than half of year and it solved my problems :).

If you like this feel free to join.

https://github.com/shumkov/grpc-everywhere

Ivan Shumkov

четверг, 28 января 2016 г., 1:23:26 UTC+3 пользователь stephen...@bigcommerce.com написал:

[lsc...@gmail.com]

The php extension : swoole, which support tcp/websocket/http2/http , can be used to implements php grpc server.

在 2016年1月28日星期四 UTC+8上午6:23:26，stephen...@bigcommerce.com写道：

[amits...@gmail.com]

On Saturday, December 10, 2016 at 9:14:14 AM UTC+11, zack....@bigcommerce.com wrote:

Just a quick update -- we've cleared the open sourcing with the rest of the team and are working to extract some proprietary bits. 

Will get something up ASAP to be evaluated for admission into the gRPC ecosystem. 

Would be keen to hear if this was ever completed?

[p.e.s...@gmail.com]

Hi Zack,

Has there been any progress on this?

Thanks,

Peter

[rodr...@gmail.com]

Has there been progress on this?

[mauro...@freedamedia.com]

This lib works quite well, thanks a lot! I hope it can be included in the official documentation.

[klingenbe...@gmail.com]

What is this lib you mention? I can't find anything in this thread actually mentioning where one can find it.

I would be very interested in trying this out.