Announcement of mitap, smoothly turning into BeerPHP drinkcap (in Moscow and online)
Hello, in August we will hold a mitap in Moscow with speakers from other cities, a BeerPHP meeting and a broadcast of the official part for all who cannot join.
Today we begin to present speakers . Sergey Zhuk will arrive at a mitap from Bryansk - there is no party in his city, and he has something to tell about asynchronous PHP: he wrote books about it, a series of articles and not only. Below is a transcript of a recent podcast about this, links to auditions and viewing of the release, as well as details about the meta.
')
Peter Myazin aka PQR : Today, one of the main experts on ReactPHP is in touch with me. Sergey, I recently visited reactphp.org and found you on the main page. You write a lot on the topic, you even have your own channel with video instructions. Tell me how you came to this, what got you hooked into ReactPHP?
Sergey aka seregazhuk : Two years ago, even at a previous job, you had to write a script that would constantly ring up customers and work very quickly. The task had to be completed “yesterday”, the team had only PHP developers, - you understand, there was no time for a new stack. But it so happened that everyone heard something about ReactPHP. He positioned himself as production-ready, everything was very easy: we just installed the company through the composer, and you could write asynchronous code. As a result, they wrote a solution on it, launched it, everyone was happy.
I realized that we have a tool - but there were no articles, practical examples like “We have such a problem, we solved it like this” in almost no Russian or English. In the end, I wrote a couple of articles on my blog, I received a positive feedback, and that’s all - it somehow dragged me on. We are accustomed to the Request-Response model, but it is worth plunging into an asynchronous code, and you will immediately ask: “Was it possible?”.
Peter: Let's talk again, what problem does the asynchronous code solve for us, and why do we need ReactPHP in particular?
Sergey: Almost every application has either API calls, or file system interaction, or database requests. When we wait for a response from them, our processor is idle - instead of doing something useful. You can not wait for an answer, but start non-blocking operations and move on. The question arises: “If we use ReactPHP everywhere for I / O, then our applications will be much faster?”
Sergey: I would think about using ReactPHP in those cases where performance is critical, and I / O is our bottleneck, which blocks everything. Moreover, I would recommend not to transfer the entire application to asynchronous rails, namely, to rewrite this particular bottleneck. As a rule, an asynchronous piece is much easier to insert into a traditional blocking code, rather than trying to rewrite the entire application completely.
Peter: Ok, but why don't we just run some PHP processes then? This is idle, but the next is engaged in business.
Sergey: And how do we then coordinate the results? Suppose we need to get data from three sources, we make calls to the three APIs, then compose the results and give them to the user. If we make three separate flows, then the problem of coordinating the result will arise.
With the asynchronous approach, we would simply run them, let's say, in parallel, then get the result and process it. When the flows have to somehow this ball to coordinate, that is, the problem with the state will be. This seems to be more complicated than the asynchronous approach.
Peter: I get it. I had such an idea in my head: if we want to increase the number of users. processed per second, how would the entire stack of applications from symfony run asynchronously and handle more connections?
Sergey: I would not do that. Often, the application does not slow down completely. If there is a performance issue, most likely there are a couple of bottlenecks inside, which are also likely to result in slow I / O. And now I would translate these bottlenecks to ReactPHP.
It would look like a small asynchronous program inside the usual blocking code: for example, we called three requests in parallel, processed them and sent a response to the user, and the total duration of execution would be equal to the time of the slowest request. If in the case of the traditional approach, we would wait for the first request, the second and the third. But the application did not become asynchronous from this.
Peter: And if we compare it all with NodeJS, say, or Go, there after all, there really is asynchrony through the entire application. All requests to the database, to the file system - they are all asynchronous inside. Does this, in principle, if you write everything in asynchronous form, it turns out some kind of profit?
Sergey: Profit will be if initially the problem is in input-output. Then yes, we will solve it. Our code will be as efficient as possible, it will be able to handle the maximum number of tasks instead of idle and wait until this output is processed. But if the problem is not initially in I / O, then writing everything asynchronously, we can hardly win, and we can get complex code that will be hard to read and maintain.
Peter: Back to PHP. So, we have ReactPHP, and from the famous analogues of Swoole, Amp and Ext-async. And tell us in comparison, what is the difference between these projects, and how good is ReactPHP, fast, and does it have any disadvantages compared to the same Swoole?
Sergey: Of all three, to be honest, I felt only Amp, and because he, like ReactPHP, is supported right out of the box. That is, we put the necessary components through the composer and is ready. And here I do not really like the stories with extensions. Because if we are left alone with PHP and asynchrony, it seems to me that it is more sensible to use language and native things - and if we use additional extensions, then there is no longer particularly asynchronous PHP, but asynchronous extensions for PHP.
Peter: They have “long-term support” written on their website. That is, some long-term support, without critical API changes. It's like that? Everything is good enough?
Sergey: Yes. The ReactPHP project itself is already quite mature. He has been working since the twelfth year, it turns out he is 7 years old. He already has enough production-ready time. And yes, more than that, long-term support has appeared for the main components for 2 years. That is, you can safely tied to these components, get fixes, updates and not worry about backward compatibility. Two years they pledge to maintain their versions, nothing breaks. This, I think, is straightforwardly really cool, this is a big step forward. As far as I remember, some time ago Amp was discussing some of its components, they were not completely determined with the interface and with their public API.
Peter: How do you recommend to start learning ReactPHP? Except the official documentation and your video lessons, of course. Where is all the community, is there any kind of telegram-chats or discord-chats, forums?
Sergey: Unfortunately, I don’t know such a direct community. There is a sufficiently active Twitter account : you can ask, ask questions and be interested. And the maintainers respond promptly enough - you can write to them personally on Twitter. I did it, I asked them for some things.
Peter: Well, thank you for such a detailed story about ReactPHP - and in connection with this I will announce the Panda Meetup , which will be held on August 22 in Moscow in the Skyeng office. You will perform there, right?
Sergey: Yes, that's right. Come, let's talk.
Peter: Also there will be a report on Domain Driven Design, which is also a cool interesting topic in the context of PHP, [and a couple of others have been added] and, as the organizers told me, there will be some afterparty.
Utility:
Today we begin to present speakers . Sergey Zhuk will arrive at a mitap from Bryansk - there is no party in his city, and he has something to tell about asynchronous PHP: he wrote books about it, a series of articles and not only. Below is a transcript of a recent podcast about this, links to auditions and viewing of the release, as well as details about the meta.
')
Peter Myazin aka PQR : Today, one of the main experts on ReactPHP is in touch with me. Sergey, I recently visited reactphp.org and found you on the main page. You write a lot on the topic, you even have your own channel with video instructions. Tell me how you came to this, what got you hooked into ReactPHP?
In fact, you are rediscovering a language in which you have been writing for many years.
Sergey aka seregazhuk : Two years ago, even at a previous job, you had to write a script that would constantly ring up customers and work very quickly. The task had to be completed “yesterday”, the team had only PHP developers, - you understand, there was no time for a new stack. But it so happened that everyone heard something about ReactPHP. He positioned himself as production-ready, everything was very easy: we just installed the company through the composer, and you could write asynchronous code. As a result, they wrote a solution on it, launched it, everyone was happy.
I realized that we have a tool - but there were no articles, practical examples like “We have such a problem, we solved it like this” in almost no Russian or English. In the end, I wrote a couple of articles on my blog, I received a positive feedback, and that’s all - it somehow dragged me on. We are accustomed to the Request-Response model, but it is worth plunging into an asynchronous code, and you will immediately ask: “Was it possible?”.
Peter: Let's talk again, what problem does the asynchronous code solve for us, and why do we need ReactPHP in particular?
Sergey: Almost every application has either API calls, or file system interaction, or database requests. When we wait for a response from them, our processor is idle - instead of doing something useful. You can not wait for an answer, but start non-blocking operations and move on. The question arises: “If we use ReactPHP everywhere for I / O, then our applications will be much faster?”
Unfortunately, you can't just take and rewrite our applications to asynchronous
This is Sergey Zhuk
Serezha is the author of ReactPHP For Beginners, Learning Event-Driven PHP With ReactPHP and PHP OOP Way books and heaps of other goodies.
Sergey: I would think about using ReactPHP in those cases where performance is critical, and I / O is our bottleneck, which blocks everything. Moreover, I would recommend not to transfer the entire application to asynchronous rails, namely, to rewrite this particular bottleneck. As a rule, an asynchronous piece is much easier to insert into a traditional blocking code, rather than trying to rewrite the entire application completely.
Peter: Ok, but why don't we just run some PHP processes then? This is idle, but the next is engaged in business.
Sergey: And how do we then coordinate the results? Suppose we need to get data from three sources, we make calls to the three APIs, then compose the results and give them to the user. If we make three separate flows, then the problem of coordinating the result will arise.
With the asynchronous approach, we would simply run them, let's say, in parallel, then get the result and process it. When the flows have to somehow this ball to coordinate, that is, the problem with the state will be. This seems to be more complicated than the asynchronous approach.
Peter: I get it. I had such an idea in my head: if we want to increase the number of users. processed per second, how would the entire stack of applications from symfony run asynchronously and handle more connections?
Sergey: I would not do that. Often, the application does not slow down completely. If there is a performance issue, most likely there are a couple of bottlenecks inside, which are also likely to result in slow I / O. And now I would translate these bottlenecks to ReactPHP.
It would look like a small asynchronous program inside the usual blocking code: for example, we called three requests in parallel, processed them and sent a response to the user, and the total duration of execution would be equal to the time of the slowest request. If in the case of the traditional approach, we would wait for the first request, the second and the third. But the application did not become asynchronous from this.
And if we compare it all with NodeJS and others?
Left - Pyotr Myazin, host of Pyatiminutki PHP
he will be on mitap and was going to jump on afterparty. If there is a topic for a new podcast, I will be happy to discuss
Peter: And if we compare it all with NodeJS, say, or Go, there after all, there really is asynchrony through the entire application. All requests to the database, to the file system - they are all asynchronous inside. Does this, in principle, if you write everything in asynchronous form, it turns out some kind of profit?
Sergey: Profit will be if initially the problem is in input-output. Then yes, we will solve it. Our code will be as efficient as possible, it will be able to handle the maximum number of tasks instead of idle and wait until this output is processed. But if the problem is not initially in I / O, then writing everything asynchronously, we can hardly win, and we can get complex code that will be hard to read and maintain.
Peter: Back to PHP. So, we have ReactPHP, and from the famous analogues of Swoole, Amp and Ext-async. And tell us in comparison, what is the difference between these projects, and how good is ReactPHP, fast, and does it have any disadvantages compared to the same Swoole?
Sergey: Of all three, to be honest, I felt only Amp, and because he, like ReactPHP, is supported right out of the box. That is, we put the necessary components through the composer and is ready. And here I do not really like the stories with extensions. Because if we are left alone with PHP and asynchrony, it seems to me that it is more sensible to use language and native things - and if we use additional extensions, then there is no longer particularly asynchronous PHP, but asynchronous extensions for PHP.
How realistic is ReactPHP production-ready?
Peter: They have “long-term support” written on their website. That is, some long-term support, without critical API changes. It's like that? Everything is good enough?
Sergey: Yes. The ReactPHP project itself is already quite mature. He has been working since the twelfth year, it turns out he is 7 years old. He already has enough production-ready time. And yes, more than that, long-term support has appeared for the main components for 2 years. That is, you can safely tied to these components, get fixes, updates and not worry about backward compatibility. Two years they pledge to maintain their versions, nothing breaks. This, I think, is straightforwardly really cool, this is a big step forward. As far as I remember, some time ago Amp was discussing some of its components, they were not completely determined with the interface and with their public API.
Peter: How do you recommend to start learning ReactPHP? Except the official documentation and your video lessons, of course. Where is all the community, is there any kind of telegram-chats or discord-chats, forums?
Sergey: Unfortunately, I don’t know such a direct community. There is a sufficiently active Twitter account : you can ask, ask questions and be interested. And the maintainers respond promptly enough - you can write to them personally on Twitter. I did it, I asked them for some things.
Peter: Well, thank you for such a detailed story about ReactPHP - and in connection with this I will announce the Panda Meetup , which will be held on August 22 in Moscow in the Skyeng office. You will perform there, right?
Sergey: Yes, that's right. Come, let's talk.
Peter: Also there will be a report on Domain Driven Design, which is also a cool interesting topic in the context of PHP, [and a couple of others have been added] and, as the organizers told me, there will be some afterparty.
Utility:
- Full audio and YouTube version of the podcast
- Link to the broadcast mitapa for those who can not come
- Details about afterparty in the telegraph BeerPHP Moscow
Source: https://habr.com/ru/post/460523/
All Articles