PHP asynchronous tcp client

EventStoreDB
1

Hello,
Here is a new client for PHP on the TCP API : https://github.com/Rxnet/eventstore-client

Feedbacks are welcome :slight_smile:

2

How do you handle the PHP process lifecycle and connection handling?

3

To write event on synchronous clients you can do

$writeResult = Rx\await(
$eventStore->appendToStream(‘category-test_stream_id’)->event(‘event_type3’, microtime(), ‘my meta data’)->commit()
);

``

For listeners or asynchronous daemon it’s made for persistent connection and listening (our main usage at work)

4

To be clear, this client primary usage is not for php-fpm, http client is better for this (with a thin overlay on Guzzle)

It’s made for php daemons (fully asynchronous is better). For example, rabbit consumer, asynchronous httpd servers, long time workers …

Where you need high throughput or low latency when a new event appeared :slight_smile:

5

I wonder if it might be better to get effort on the c client and then
wrap it with a PHP wrapper moving forward as it could be reused in
other environments such as python.

6

It’s a good idea, extension is always faster, but how would you handle multi tasking ?

We need an eventStore with parallel competing consumers, that’s why eventLoop based (and reactiveX) is great

One php process can handle 10 or more events in parallel (to project in elasticsearch or rabbit) if I need more or if projection is slow, I multiply the number of PHP processes.

7

makes total sense!

8

For multi-tasking it would be done in C with callbacks. I imagine this
could be wrapped to support PHP though have to admit my ignorance on
the PHP side as I last wrote PHP close to 15 years ago :-/

9

C extension have one drawback, too few people can contribute.

You have to know C and PHP to make it works.

With protocol buffer it’s relatively easy to write a driver.

The HTTP version is perfect to taste and see all the advantages.

In my opinion, you miss only few thinks :

  • a documentation for writing a driver (like this one https://rethinkdb.com/docs/writing-drivers/) could help a lot to build new driver (the PersistentSubscriptionAckEvents subscriptionId with its streamId::group was a pain for example)

  • v2 and v3 .proto that are easy to find

10

Yes the documentation around writing drivers could definitely be
improved. My favourite example of the is :
https://github.com/gregoryyoung/libesclient/blob/master/src/wtf_uuid.c
if you have not run into it.