Comments (12)
I don't think supporting Thenables in the coroutines would be an issue. It's more that we'd need an event loop adapter.
from amp.
The thing is, going through an application and re-factoring all the code which is coupled to a specific event loop is far less work than re-factoring all the code which is coupled to a specific promise implementation.
The project I'm working on at present is deployed to AWS which means virtually all our services are accessed over HTTP. We pretty much only reference the event loop when setting up the HTTP clients in our DI config.
The thing which is making my life hard is the lack of interoperability with thenables.
from amp.
The project I'm working on at present is deployed to AWS which means virtually all our services are accessed over HTTP. We pretty much only reference the event loop when setting up the HTTP clients in our DI config.
Where are these thenables created and resolved? They have to be coupled to the event loop somewhere.
The thing is, going through an application and re-factoring all the code which is coupled to a specific event loop is far less work than re-factoring all the code which is coupled to a specific promise implementation.
Can't you just write a function that creates a promise from a React thenable?
from amp.
@kelunik It's not that easy, React libs register their events on the react loop too.
What we need is a full-blown adapter library.
(But I'm all in favor of finally doing that.)
from amp.
@bwoebi: That's what I said.
from amp.
I agree that an event loop adapter would be great, but I believe there is still a lot of value in supporting thenables in the coroutine implementation even without a reactor/loop adapter. In fact, my experience leads me to believe that promise interoperability provides far more real world value than event loop interoperability despite being much easier to implement (it would take five minutes).
Where are these thenables created and resolved? They have to be coupled to the event loop somewhere.
Firstly, I assume we'd all agree that none of the popular promise implementations in PHP are inherently coupled to a specific event loop, nor should they be.
But I don't think that's what you're saying, and maybe I need to provide more detail on my current situation and why I'm asking for this feature.
I'm currently leading a team of five which is working full time developing an asynchronous SaaS application which is deployed to AWS and written in PHP. The backend application currently comprises around 50 PHP packages. Only one of those packages requires a specific event loop implementation, but almost all of them work with thenables of different kinds.
Our application is stateless and consumes a number of services, most of which are AWS services. These include SQS (message queue), S3 (object store), DynamoDB (document store), SES (email service), Mandrill (another email service), keen.io (analytics). Guess how many places we reference the event loop at present? One place. That's because all of these services are interacted with over HTTP, which means all of our IO is over HTTP. We create a single Guzzle handler which is injected to Guzzle clients all over our application by our DI container. We define interfaces for things like document stores and distributed lock services, and then provide implementations of these interfaces using AWS services, using the AWS SDK, and finally wrap these services in higher-level services such as entity repositories. But none of these layers have a need to reference the event loop directly. The only place we touch the event loop is to periodically tick Guzzle's curl handler. To switch over to Amp's loop, I literally only have to change a few lines of code in a configuration package. As a future task I can potentially create a Guzzle handler using Artax (I don't see PSR 7 streams as a major barrier) if this provides greater efficiency.
As you can see, real-world code is massively more coupled to specific promise interfaces than it is to specific reactors, and so reactor/event loop interoperability, which I don't believe we'll have any time soon, doesn't really buy me much, despite being quite a lot of work.
Can't you just write a function that creates a promise from a React thenable?
My controllers return generators, so I would have to write a function which translates these generators from yielding thenables to yielding only Amp promises, which is far more complicated than adding thenable support to Amp's coroutine implementation, as well as creating an unnecessary performance hit.
from amp.
There's now a possible PR: #44. But I'm not really happy with it. Currently it adds a dependency to react/promise
. Unfortunately, they didn't separate the PromiseInterface
from the other things, so we probably have to depend on ^1|^2|^3
.
I still think it's better when you transform the react promises yourself before yielding them in an Amp coroutines. This ensures we keep our code base clean and don't have any issues going forward whatever ReactPHP decides to do.
from amp.
https://github.com/DaveRandom/Loopio
Quite out of date but could probably be made to do the job rather than having to start from scratch.
from amp.
https://github.com/DaveRandom/Loopio
Quite out of date but could probably be made to do the job rather than having to start from scratch.
Thanks for the heads up.
from amp.
This will be part of Amp v2.0 which will implement the event-loop and awaitable standards.
from amp.
just for reference. "standards" means what https://github.com/async-interop will define.
from amp.
Closing as we won't support thenables, but the Awaitable
standard then.
from amp.
Related Issues (20)
- Return self in Future::ignore HOT 1
- UnhandledFutureError is hard to debug HOT 2
- Migration guide for combinator functions HOT 5
- FiberError: Cannot switch fibers in current execution context on Laravel HOT 4
- 32 bit PHP: Return value of Amp\Loop\NativeDriver::now() must be of the type int, float returned HOT 5
- Functions should require callable instead of closures HOT 10
- Any way to create or get a context for coroutine. HOT 5
- Version confusion HOT 8
- Shouldn't Future::finally() pass the future data to the provided callback? HOT 7
- Event loop terminated without resuming the current suspension (the cause is either a fiber deadlock, or an incorrectly unreferenced/canceled watcher) HOT 3
- Future combinators HOT 8
- When to not to use `async`?
- Comparison with ReactPHP HOT 8
- The docs not up to date? HOT 3
- Where is this `any()` function?
- Interception of pause / resume future HOT 2
- Add Payload::readEntireBody? HOT 3
- Symfony Messenger Integration HOT 4
- Using AMPHP with Psalm HOT 5
- onComplete event for async? HOT 9
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from amp.