Project Architecture and Definition

[devsdmf]

Hi @tpunt, hope you're going well!

First of all, you're the man, this is an awesome project that was in my mind since two weeks and I came from a conference last week thinking in implement this in PHP, so I'd love to help you in this project!

Second, I was looking at the source code and it is sound a bit confusing for me yet. I'm working with Actor Model using Scala (Akka) and I was thinking how would we implement the runtime architecture. I mean, in Scala w/ Akka, when we run the application, we start it like a daemon (using the internal Akka Http Server or Netty server) and I was thinking how we would architect the runtime of a PHP app using the Actor Model? TCP Sockets? PHP Built-in Web Server? ReactPHP

There are some other things to care about, like clustering the application, we may need a node coordinator, a sharding model, a persistence model and etc...

Again, I would love to help you in this journey as I'm loving work with Actor Model in Scala and this would be a good step in architecture point-of-view of PHP apps.

If is good for you, we can make a discussion group to take this project to a next level.

Let me know what you think about this, ok?

Best regards!

[tpunt]

Hi @devsdmf

I'm glad to hear you're interested - it would be nice to have some help with this project!

I'm working with Actor Model using Scala (Akka) and I was thinking how would we implement the runtime architecture.

Upfront: I'm not that familiar with Akka - I'm more familiar with Erlang's Actor model implementation. But it would be great to get ideas from both projects.

Regarding the runtime architecture question: PHP's built-in web server is not suitable, due to its limited concurrency. ReactPHP has good concurrency, but a different concurrency model. I think we should keep the whole runtime architecture actor-ised, so that we can directly benefit from aspects of the Actor model (as well as from its implementation details), such as failure isolation, failure handling (supervision trees), vertical scaling (because of the N:M threading model used), etc.

Implementing it can be done (for now) using actors and the sockets extension. In future, though, I'd like to integrate libuv into the project to provide a set of internal, non-blocking APIs. These can reuse the message handling loop to automatically interrupt actors for IO-blocking tasks (similar to what Go does with its CSP model), and reschedule the actors automatically when the data for their IO-bound task becomes available.

But that is some way into the future. In fact, it's still probably a little premature to even be thinking about the runtime architecture. For now, the focus should be on stabilising the extension (fixing bugs/memory leaks, adding platform support, etc), and on the supervision trees enhancement. With those things done, then we can begin developing useful applications with phactor (such as the runtime stuff).

There are some other things to care about, like clustering the application, we may need a node coordinator, a sharding model, a persistence model and etc...

Yep, those are planned for much later - when remote actors are implemented.

If is good for you, we can make a discussion group to take this project to a next level.

I don't mind having a separate discussion group (e.g. for questions on the extension's internals), but it would probably be best to keep most of the discussions on this repo. That would more easily allow for other developers to input their thoughts, as well as keep the discussions more organised.

Thanks!