search

amphp / http-server

An advanced async HTTP server library for PHP, perfect for real-time apps and APIs with high concurrency demands.
https://amphp.org/http-server
MIT License
1.28k stars 100 forks source link

PSR-7 compliance #357

Open mschop opened 10 months ago

mschop commented 10 months ago

Hi,

I am trying to write an integration between a framework (https://packagist.org/packages/phespro/phespro) and amphp http server.

Unfortunately amphp/http-server does not follow PSR-7 (https://www.php-fig.org/psr/psr-7/).

The class \Amp\Http\Server\Request does not implement \Psr\Http\Message\ServerRequestInterface

This prevents me from simply forwarding the request to the kernel of that framework (which would have been a no brainer).

Why does amphp/http-server not follow that standard? Are there any plans to support PSR-7 in the future?

Thanks in advance!

Best Regards Martin

trowski commented 10 months ago

Hi @mschop!

This library does not follow PSR-7 because the interfaces do not fit well into a non-blocking application and do not fit into the eco-system we've created in Amp using components such as ReadableStream, designed for non-blocking consumption.

However, with fibers improving integration of sync and async code, providing an adaptor should be an easy task. I started this some time ago in trowski/psr-http-bridge with v2 of this library and intend to update it to v3 and port the library to this project.

Ideally, because requests may perform blocking actions, clients would be spread amongst a pool of worker processes. This is on our roadmap, likely in another library using amphp/cluster

raghuveer commented 10 months ago

interested to see PSR-7 support for Amphp http server

mschop commented 8 months ago

@trowski Could you maybe add more detail on why PSR-7 does not fit well into this kind of non-blocking application?

\Psr\Http\Message\ServerRequestInterface and \Psr\Http\Message\ResponseInterface use a stream for the body.

Btw. ReactPHP HTTP server uses PSR-7.

mschop commented 8 months ago

Idea:

I will use react/http for handling incoming http connections with my framework. Inside of my application I will use revolt/event-loop-adapter-react for being able to use the amphp.

Do you think this is a suitable approach, or are there any drawbacks on this approach?

kelunik commented 8 months ago

@mschop The doesn't fit well with non-blocking I/O is rather an argument of the past, it could work fine now. However, our current interface fits better with the amphp ecosystem, which has its own stream interface.

I'd be great if there was a proper stream interface PSR, but unfortunately, this was put into the HTTP PSR at that time and a bit too focused on the existing PHP SAPI.

You can of course also just use react/http and revolt/event-loop-adapter-react. It will be a different server implementation then and you'll loose features like HTTP/2 support, but that might not be too impoartant for an application server that's running behind a load balancer like Nginx.

We plan to eventually have a PSR-7 adpter on top of our current API, but we don't plan to make our API directly depend on PSR-7 here.

mschop commented 8 months ago

@kelunik Thank you for pointing out that react/http does not support HTTP/2. This is not ideal, but OK for now.

A PSR-7 adapter would be great :+1: .

raghuveer commented 5 months ago

We plan to eventually have a PSR-7 adpter on top of our current API, but we don't plan to make our API directly depend on PSR-7 here.

it will be really nice to have PSR-7 support through PSR-7 adapter