Mercure VS React

Are you aware of things like websockets and mercure.rocks?

It could be implemented with STOMP, or Mercure (goes well with API-Platform, written in PHP/Symfony), you could write your own with the help of nchan and scale it via Redis. If it's a web service, the best practices for operating and scaling are well established, Godot then just becomes another client.

You can try https://mercure.rocks/.

It's worth looking at something like Mercure , which is used by API Platform

Pusher might be one of these systems, Mercure is another one (which you can host yourself). Mercure has good documentation and some examples in various languages, including PHP: https://mercure.rocks/docs/ecosystem/awesome#examples.

You can use Mercure https://mercure.rocks/ , Mercure uses http2.

I actually was thinking about this when I saw https://github.com/dunglas/mercure project to become a Caddy plugin. But I did not find enough reasoning to try this with Centrifugo at that point, and still... Seems awesome from one side - tight integration with a web-server, no extra network between LB and Centrifugo. But will this be useful in practice and find its users? 🤔 That's the question I don't have an answer yet.

Polling is kind of ok (data might change between poll events), but real-time updates are better. So If you don't mind adding an extra service, then take a look at mercure.

Two more questions: - Am I to understand The Guild now recommends GraphQL Yoga over Helix? - Could something like Mercure be included in the recipes ? (this would be a nice solution for serverless)

ReactPHP is a library that allows you to turn PHP into something like Go or Node.js so that tasks can be performed asynchronously. Note that ReactPHP is just a library that you install with Composer. It doesn’t have cumbersome requirements, such as installing a custom PHP extension; it just works as intended.

ReactPHP is categorized as a low-level dependency for event-driven programming. It features an event loop that supports low-level utilities, such as HTTP client/server, async DNS resolver, streams abstraction, and network client/servers.

So you could either skip the framework entirely and shave of these 10ms per request, or you could turn to something like Laravel Octane or ReactPHP to have a long running application that answers requests without bootstrapping the whole framework each time (which is what Node.js, Python or .NET applications do, the practice of restarting the whole app with every request is quite unique to the PHP community).

I remember calling out the movement to serverside of the frontend framework as reactPHP (I think it's when the remix hype first surfaced) on twitter and realized there's a literal php framework called reactPHP (https://reactphp.org/) since they liked my tweet lol.

https://reactphp.org/ of course.

You could also use something like EventMachine (In ruby), Twisted (Python), Node (JS) or ReactPHP (for PHP) that will use the language and turn it into a web application server, and then you'll have only one long running process that handle all your requests with shared memory. You could even use something more fancy like RoadRunner in the case of PHP.

Comparing PHP to NodeJS is completely wrong to begin with. If you want to compare NodeJS to something in the PHP ecosystem it would be ReactPHP.

Dunno about PHP core, but there is also ReactPHP. https://reactphp.org/

There are many micro-frameworks available like Slim, Mezzio(with Swoole may be), or if you are into async then you can also try Framework X(from core maintainer of ReactPHP). This frameworks have small footprints compare to Laravel, Symfony, etc. Yes, you can't get things like authentication, routing and other out of the box but they can easily be installed and configured to be used.