Comparison with ReactPHP about amp HOT 8 OPEN

Blocking IO should generally be avoided our moved into separate threads using amphp/parallel. Sometimes, blocking for a short time might be acceptable for your application, e. g. during initialization.

from amp.

I can clear up a few things but one of the maintainers can provide more insight into the internals and comparisons than I can. First, the current amphp version is 3, and most packages have some development or release tag compatible with amphp v3. There is some documentation but not a lot. The best learning resources are reading the tests, examples, and source code of those respective packages. There are almost no community answers (other than Github issues) relating to v3 that I've found.

I'm trying to use Guzzle as a HTTP client as I need support for digest authentication. I settled with Guzzle because I saw it had Async support but then I realised that it uses its own promise implementation.

I've replaced the Guzzle HTTP driver with amphp/http-client but I would recommend just using amp and implementing digest authentication yourself. It will be easier.

await() in AMPPHP behaves completely differently to the way it does in JS and React and I don't understand why. When I first read the docs, I assumed await() would await a promise/future to complete in a synchronous-like way. But I eventually realised that it only takes a collection of promises and futures.

There are two awaits. Maybe the naming could be improved, but their difference is covered in the amp docs https://github.com/amphp/amp. Make sure to read entire page, including the article titled "What color is your function?" referenced because that should help elucidate some of the differences between PHP and JavaScript when it comes to async.

1. Amp\Future::await() https://github.com/amphp/amp?tab=readme-ov-file#motivation
2. Amp\Future\await() https://github.com/amphp/amp?tab=readme-ov-file#await

If you look at the source code, you'll see that the await() taking a list of Futures really just calls Future::await() and it's also declared as a function in a namespace whereas the other is an instance method in the Future class.

It would be good to understand what the advantages are of using AMPHP + Revolt vs React Async + React EventLoop

Revolt actually provides an adapter so you don't have to choose. You can run React and Amp libraries on the same Revolt event loop https://github.com/revoltphp/event-loop-adapter-react

most examples relate to JS

When using Amp, I have found it's best to not relate it to JS. You will see similar async programming concepts but you don't have the same language limitations of JS. Calling async or sync functions is identical and so it can ease some burden on the programmer for having to know whether something is async or not. The benefit of fibers is that it will work regardless.

from amp.

To take advantage of asynchronous PHP I'm investigating the options. @bennnjamin mentions the What color is your function? reference. It describes side effects of changing code fom synchronous to asynchronous.

AMPHP does not have that specific problem. But as far as I understand, a similar problem exists: you can no longer use any standard PHP I/O functions.

AMPHP has it's own database drivers, HTTP clients, stream implementation. That means existing code in my application or from external packages has to be rewritten if they are called inside an asynchronous function. So , no ORM that uses PDO, or the normal file read/write functions.

Is that correct?

from amp.

@robopzet Yes, but that applies to all asynchronous libraries.

from amp.

I see. That's unfortunate.

from amp.

you can no longer use any standard PHP I/O functions.

You can, they just aren't asynchronous.

That means existing code in my application or from external packages has to be rewritten if they are called inside an asynchronous function

Ideally you would use something like amphp/parallel to avoid blocking the main event loop if you have code that might block for an insignificant period of time.

It's non-trivial, but you can try to replace the PDO driver in an ORM with one provided by Amp. I have done it with a popular ORM but end up abandoning it as most PHP libraries are not written to be used in an async, long-running process and so even if you can get it working you will likely run into other issues.

from amp.

Wrapping your code in async doesn't make it magically non-blocking. Blocking IO will keep blocking.

from amp.

Would there be no point in even wrapping it async? If so, I will update my comment. Would it be correct to say that integrating blocking code in the event loop should be avoided at all costs?

from amp.