WEBVTT NOTE Created by CaptionSync from Automatic Sync Technologies www.automaticsync.com 00:00:00.276 --> 00:00:03.686 align:middle Hello, good morning. 00:00:03.686 --> 00:00:14.526 align:middle So, roughly six months ago we released the Symfony 4.1. 00:00:14.886 --> 00:00:18.516 align:middle And that was the first time that we actually introduced the Symfony Messenger Component. 00:00:19.306 --> 00:00:23.506 align:middle So today what I want to talk about is obviously this component. 00:00:23.566 --> 00:00:26.676 align:middle I want to quickly introduce it and that's going to be the first part of the talk. 00:00:26.916 --> 00:00:31.896 align:middle And then sort of like explain what's, what has changed in the, during the transition 00:00:31.896 --> 00:00:37.306 align:middle from the 4.1 and the version 4.2, that was actually released a few days ago I think. 00:00:38.216 --> 00:00:41.016 align:middle Before that, I'll introduce myself very quickly. 00:00:41.016 --> 00:00:46.376 align:middle I'm Samuel Rozé, I'm part of the Symfony core team, the ApiPlatform as well 00:00:46.376 --> 00:00:50.726 align:middle and I've created a bunch of open source things like ContinuousPipe and Tolerance. 00:00:50.726 --> 00:00:55.316 align:middle I don't have any time to present them but you should check these out, it's quite interesting. 00:00:56.036 --> 00:01:01.086 align:middle Very quickly, the startup I'm working with, we are on a mission in trying 00:01:01.086 --> 00:01:04.026 align:middle to help the old people, the elderly to stay healthier and longer 00:01:04.026 --> 00:01:06.586 align:middle at home instead of going to retirement houses. 00:01:06.906 --> 00:01:08.926 align:middle It's, to me a very interesting project. 00:01:09.446 --> 00:01:11.676 align:middle You should check the website, it's birdie.care. 00:01:12.086 --> 00:01:16.696 align:middle Obviously as most of the technology companies we are actually hiring. 00:01:17.156 --> 00:01:18.976 align:middle So if you're interested, talk to me. 00:01:19.486 --> 00:01:22.206 align:middle So Symfony Messenger. 00:01:22.726 --> 00:01:24.066 align:middle So what it is? 00:01:24.176 --> 00:01:29.826 align:middle There are five main concepts within the actual, within Symfony Messenger. 00:01:30.376 --> 00:01:31.896 align:middle The first one is messages. 00:01:31.896 --> 00:01:33.816 align:middle You could have guessed it. 00:01:34.266 --> 00:01:36.406 align:middle So it's your PHP object. 00:01:36.656 --> 00:01:40.956 align:middle It's a PHP class that you will create that you will dispatch somewhere 00:01:41.426 --> 00:01:46.366 align:middle and you will dispatch this message to a message bus. 00:01:46.586 --> 00:01:50.836 align:middle Then once the message has been dispatched to the bus, the bus's responsibility is 00:01:50.866 --> 00:01:56.786 align:middle to actually call some things that are going to contain the business logic, your business logic, 00:01:57.126 --> 00:01:58.976 align:middle and these things are called message handlers. 00:01:59.936 --> 00:02:06.606 align:middle It's a bunch of classes, no specific requirement, it's, um, what you want to execute 00:02:06.836 --> 00:02:09.276 align:middle when you receive, when the code receive the message basically. 00:02:09.456 --> 00:02:13.506 align:middle You can have zero to N handlers for a given message. 00:02:14.456 --> 00:02:17.136 align:middle Just these three points are really super valuable. 00:02:17.396 --> 00:02:23.906 align:middle And if you're into, um, sort of design patterns or sort of like interesting things like CQRS 00:02:23.906 --> 00:02:27.206 align:middle if you've heard about it, the idea is 00:02:27.206 --> 00:02:30.626 align:middle that we can actually structure an entire application around the bus. 00:02:30.626 --> 00:02:34.346 align:middle And we can actually structure an entire application around a bus or multiple buses. 00:02:34.446 --> 00:02:38.196 align:middle But the point is that we can actually do really, really, um, 00:02:38.196 --> 00:02:43.206 align:middle decouple who is dispatching a message from who is actually handling the message. 00:02:43.896 --> 00:02:45.826 align:middle I won't go that much into the details. 00:02:46.076 --> 00:02:50.856 align:middle The important takeaway here is that just these 3 concepts, without talking about asynchronous, 00:02:50.856 --> 00:02:53.696 align:middle without talking about queue all of that, is already extremely valuable 00:02:53.946 --> 00:02:56.386 align:middle and you should actually try to play with them. 00:02:56.846 --> 00:03:01.116 align:middle Turns out, that also we didn't have a solution for asynchronous things in Symfony. 00:03:01.676 --> 00:03:06.486 align:middle So one of the other concept in the Symfony Messenger component is the notion of transport. 00:03:06.516 --> 00:03:11.356 align:middle So we can actually say, well, instead of actually directly calling the message handler 00:03:11.686 --> 00:03:16.936 align:middle or your message handler, well, the bus can actually switch to something else. 00:03:16.936 --> 00:03:19.426 align:middle We can actually route the message to actual, to a transport. 00:03:19.956 --> 00:03:23.586 align:middle And the transport is really something a bit abstract, but something is responsible 00:03:23.966 --> 00:03:26.236 align:middle of talking to your, to a third party. 00:03:26.466 --> 00:03:32.256 align:middle The most famous one is RabbitMQ being a third party, so queuing mechanism. 00:03:32.666 --> 00:03:35.906 align:middle But technically it can be actually anything, can be Gearman if you want 00:03:35.906 --> 00:03:41.056 align:middle to do some distributed processing for your messages, can be an API, there is no real limit. 00:03:41.786 --> 00:03:47.896 align:middle And the last missing dot here is that if you actually dispatch the message and you route it 00:03:47.896 --> 00:03:50.546 align:middle to a transport, it's in the queue, but nothing will happen. 00:03:50.986 --> 00:03:54.036 align:middle So the fifth sort of concept is this notion of worker. 00:03:54.516 --> 00:03:58.176 align:middle So it's just something that is going to say, or ask the transport: "hey, 00:03:58.386 --> 00:04:01.716 align:middle tell me when I receive a message" And when a message arrives, 00:04:01.716 --> 00:04:03.456 align:middle it will actually call your message handler. 00:04:04.136 --> 00:04:10.326 align:middle The same thing as a sort of a graphical representation. 00:04:10.676 --> 00:04:13.266 align:middle You've got a message, you dispatch a message to a message bus, 00:04:13.496 --> 00:04:18.106 align:middle that is handled by one or zero or N handlers. 00:04:18.656 --> 00:04:24.526 align:middle If you really want to, you can route this message to a subset of transports: 00:04:24.616 --> 00:04:28.386 align:middle to one or multiple transports, instead of directly calling the handler. 00:04:29.176 --> 00:04:34.296 align:middle These transports are responsible for talking to these guys, and we've got the worker 00:04:34.296 --> 00:04:37.716 align:middle that is responsible for receiving the message from the transport 00:04:37.716 --> 00:04:39.716 align:middle and dispatching them back to the message bus. 00:04:41.256 --> 00:04:45.656 align:middle Now the important thing here is that actually, if you actually route the message to a transport 00:04:46.016 --> 00:04:51.706 align:middle within your HTTP server - or your like main PHP thread - um, you actually dispatch the message 00:04:51.706 --> 00:04:53.196 align:middle and your handler won't be called. 00:04:53.196 --> 00:04:55.236 align:middle It will be super fast, you will hand it to the queue. 00:04:55.616 --> 00:04:57.566 align:middle And you need to run this worker somewhere else. 00:04:57.566 --> 00:05:01.136 align:middle So you won't be on your web server, might be somewhere else on another machine, 00:05:01.626 --> 00:05:06.556 align:middle but the code that your handler contains, or your message handler contains, 00:05:06.556 --> 00:05:11.116 align:middle is going to be executed outside of the PHP context or the web context. 00:05:11.366 --> 00:05:14.076 align:middle That's the main, that's the main concept. 00:05:14.596 --> 00:05:20.816 align:middle So now I'm going to show you exactly how from a user perspective 00:05:20.816 --> 00:05:23.466 align:middle or developer perspective, how can we use it. 00:05:27.256 --> 00:05:30.726 align:middle You all have seen, I guess what a Symfony controller looks like. 00:05:31.206 --> 00:05:34.446 align:middle Now it's fairly recent, but it's a few versions already, 00:05:34.446 --> 00:05:37.876 align:middle we can inject services directly in the action arguments. 00:05:37.916 --> 00:05:44.096 align:middle So in this example here, I'm going to inject a MessageBusInterface that is already configured 00:05:44.096 --> 00:05:49.066 align:middle and wired for you if you have the component installed on your Symfony framework application. 00:05:50.296 --> 00:05:53.936 align:middle What you can do, as I mentioned, you can actually dispatch using, 00:05:53.936 --> 00:05:57.136 align:middle calling dispatch method, on the bus, you can dispatch your message. 00:05:58.106 --> 00:05:59.556 align:middle There is no requirement. 00:05:59.556 --> 00:06:02.906 align:middle I mentioned that already, but there is no requirement: that's how your message looks like. 00:06:03.296 --> 00:06:04.416 align:middle It's your own php class. 00:06:05.736 --> 00:06:06.846 align:middle So whatever you want to do. 00:06:06.846 --> 00:06:10.116 align:middle If you want to actually send a notification, you can call it a SendNotificationMessage. 00:06:10.216 --> 00:06:16.206 align:middle If you want to, I don't know, buy pizza, it can be BuyPizzaMessage. 00:06:17.126 --> 00:06:20.576 align:middle You can put the properties you want, you can put the method, the getters, 00:06:20.576 --> 00:06:22.596 align:middle the setters you want it is completely your own code. 00:06:23.356 --> 00:06:24.086 align:middle There's nothing... 00:06:24.276 --> 00:06:27.716 align:middle to compare with the event-dispatcher for example, where the event needs 00:06:27.756 --> 00:06:30.576 align:middle to extend the Event class, well, we don't need that anymore. 00:06:30.876 --> 00:06:32.406 align:middle At least in this component. 00:06:32.836 --> 00:06:36.466 align:middle Once you've dispatched your message, guess what? 00:06:36.466 --> 00:06:37.986 align:middle You need a message handler. 00:06:38.776 --> 00:06:41.506 align:middle Same idea: there is no specific requirement on the message handler. 00:06:41.506 --> 00:06:44.846 align:middle The only thing is it needs to be a PHP callable. 00:06:45.506 --> 00:06:47.356 align:middle So typically it can be an anonymous function. 00:06:48.186 --> 00:06:52.086 align:middle In our beautiful world of classes and all of that, 00:06:52.236 --> 00:06:56.676 align:middle it is a class that has a method, a magic method named __invoke(). 00:06:56.676 --> 00:07:02.236 align:middle If you type-hint your message, type-hint your message, as the first argument 00:07:02.236 --> 00:07:05.886 align:middle of the __invoke method, then Symfony will automatically understand 00:07:05.886 --> 00:07:08.376 align:middle that it is this message that you want to handle. 00:07:09.486 --> 00:07:12.106 align:middle And when you dispatch the message this handler is going to be called. 00:07:12.106 --> 00:07:14.936 align:middle There is a slight tweak here. 00:07:15.616 --> 00:07:20.736 align:middle It's just that in order for Symfony to automatically configure your handler, 00:07:21.586 --> 00:07:25.206 align:middle and automatically add the tag required to actually discover your handlers, 00:07:25.736 --> 00:07:27.216 align:middle you can use this marker interface, 00:07:27.486 --> 00:07:34.236 align:middle and this marker interface is called MessageHandlerInterface and contains nothing. 00:07:34.236 --> 00:07:37.296 align:middle You don't have any requirements, but just to say to Symfony: "Hey, 00:07:37.546 --> 00:07:42.476 align:middle can you wire that handler into the message bus?" 00:07:42.476 --> 00:07:43.236 align:middle Okay, cool. 00:07:43.776 --> 00:07:45.996 align:middle Now, if you run that code, your handler, 00:07:45.996 --> 00:07:48.506 align:middle whatever your domain logic is will be run synchronously. 00:07:49.216 --> 00:07:54.056 align:middle So that's the simplest way of registering a message handler. 00:07:54.086 --> 00:07:56.636 align:middle You've got another way which is very similar to the... 00:07:56.816 --> 00:07:58.746 align:middle what we've done with event dispatcher component. 00:07:58.836 --> 00:08:01.976 align:middle We've got a MessageSubscriberInterface. 00:08:02.626 --> 00:08:05.846 align:middle What you can say is that, you can say, well, this handler 00:08:05.846 --> 00:08:11.216 align:middle or this class will actually handle this message and this message and this message. 00:08:11.216 --> 00:08:16.136 align:middle You can handle multiple messages and you can also give it a very interesting configuration. 00:08:16.606 --> 00:08:20.626 align:middle So you can say that, so the syntax it's a bit different, 00:08:20.626 --> 00:08:23.076 align:middle it's using yield instead of returning an array. 00:08:23.816 --> 00:08:25.316 align:middle There is a technical reason to that. 00:08:26.116 --> 00:08:33.036 align:middle But the main thing here is the return value or the value of your yield can be a set of options. 00:08:33.456 --> 00:08:37.316 align:middle So you can actually say instead of the default __invoke method, you can say, well, 00:08:37.516 --> 00:08:38.886 align:middle let's call the doSomething() method. 00:08:39.506 --> 00:08:41.676 align:middle You can also configure the bus. 00:08:41.676 --> 00:08:47.486 align:middle So if you've got multiple buses, for most of, you are using an event bus or command bus 00:08:47.486 --> 00:08:51.166 align:middle or this kind of stuff, you can actually say, well, this subscriber 00:08:51.216 --> 00:08:55.256 align:middle or this handler will actually just listen for this message on this specific bus. 00:08:55.766 --> 00:09:02.526 align:middle You've got a notion of priority as well, etc. An interesting point of using the yield instead 00:09:02.576 --> 00:09:10.196 align:middle of returning just an array is that we can yield multiple time the exact same key. 00:09:10.426 --> 00:09:14.346 align:middle So we can have multiple configuration for the same message, so we can actually, 00:09:14.686 --> 00:09:18.346 align:middle we can have the handler be called twice if we use the same message key 00:09:18.346 --> 00:09:19.666 align:middle but different priorities as the value. 00:09:20.616 --> 00:09:21.296 align:middle It's very interesting. 00:09:22.176 --> 00:09:25.466 align:middle Anyway, I'm not sure you're going to use that all the time, but that's another way 00:09:25.466 --> 00:09:28.136 align:middle to register the message subscribers. 00:09:31.476 --> 00:09:35.726 align:middle Now, very important, by default, every single message is handled synchronously. 00:09:36.316 --> 00:09:46.436 align:middle And I think it's a pattern that starts to be, we can start to see if you've watched or listened 00:09:46.436 --> 00:09:50.396 align:middle to the Symfony Mailer, announcement from Fabien a few conferences ago, 00:09:50.996 --> 00:09:55.566 align:middle actually the idea would be that the more and more we ship the more, maybe, 00:09:55.566 --> 00:09:59.526 align:middle you would just be able to dispatch a message into the bus. 00:09:59.526 --> 00:10:04.816 align:middle And that would be a sort of a nice way to provide extension points 00:10:04.816 --> 00:10:07.826 align:middle from library perspective: here's all the messages you can dispatch 00:10:07.826 --> 00:10:12.596 align:middle and that is going to do the job. 00:10:12.596 --> 00:10:15.696 align:middle Now if you actually have a message handler 00:10:15.976 --> 00:10:19.406 align:middle that is a bit too slow - and that is the main use case. 00:10:19.836 --> 00:10:22.846 align:middle If it is too slow, what you can say is that either you wait. 00:10:24.386 --> 00:10:27.806 align:middle Or you can, well you can configure this message bus to say, 00:10:27.806 --> 00:10:30.686 align:middle I'm going to route this message somewhere else. 00:10:30.796 --> 00:10:33.266 align:middle And to this message you're going to route it to a transport. 00:10:33.876 --> 00:10:34.956 align:middle So how are you going to do it? 00:10:35.246 --> 00:10:36.956 align:middle Well, first thing you're going to create a transport. 00:10:37.736 --> 00:10:43.286 align:middle So transport is something that can be created from a DSN or URL here. 00:10:43.286 --> 00:10:43.746 align:middle If you.... 00:10:43.746 --> 00:10:46.866 align:middle Actually, who here is actually is using Doctrine? 00:10:47.216 --> 00:10:52.026 align:middle I was expecting more people. 00:10:52.706 --> 00:10:59.366 align:middle So half of the room actually admit they use Doctrine. 00:10:59.866 --> 00:11:03.256 align:middle So the idea is simple: you've got a database URL in Doctrine, 00:11:03.256 --> 00:11:06.116 align:middle so you can configure whether it's MySQL or Postgres database. 00:11:06.326 --> 00:11:07.316 align:middle Here is the same example. 00:11:07.796 --> 00:11:11.186 align:middle The transport: you give it a name, you give it the name rabbit, 00:11:11.296 --> 00:11:16.036 align:middle it's completely up to you give it the name you want, and the main configuration is the DSN. 00:11:16.096 --> 00:11:20.806 align:middle When you create the transport, you run the same code it's going to be as slow as before. 00:11:21.216 --> 00:11:23.166 align:middle Because creating a transport doesn't do anything. 00:11:23.486 --> 00:11:27.256 align:middle What does something is when you route the message... 00:11:27.366 --> 00:11:30.146 align:middle explicitly routing a message to a specific transport. 00:11:31.126 --> 00:11:36.586 align:middle So here you say your App\Message\YourMessage is going to be routed to the rabbit transport. 00:11:37.646 --> 00:11:41.806 align:middle Here I just put the actual class, but it can be a parent class or an interface, 00:11:41.876 --> 00:11:44.716 align:middle that works as well, so we can route a specific set of messages. 00:11:44.846 --> 00:11:49.406 align:middle And if you rerun the application, wow! 00:11:50.536 --> 00:11:52.426 align:middle Now super fast. 00:11:53.966 --> 00:11:55.286 align:middle The only problem is... 00:11:56.136 --> 00:11:57.936 align:middle Nothing happened, obviously. 00:11:58.006 --> 00:12:01.606 align:middle Because this message has been sent to a queue, in this example RabbitMQ queue, 00:12:02.226 --> 00:12:07.506 align:middle but we didn't consume it, so we didn't run the actual handlers. 00:12:07.596 --> 00:12:10.806 align:middle And that's the fifth point, which is just the worker. 00:12:11.236 --> 00:12:12.536 align:middle The worker look like a... 00:12:13.006 --> 00:12:13.966 align:middle just a Symfony command. 00:12:14.676 --> 00:12:20.006 align:middle So you run bin/console messenger:consume-messages into another machine, 00:12:20.006 --> 00:12:23.616 align:middle on another machine, and this will listen for messages and consume them. 00:12:24.106 --> 00:12:25.296 align:middle That's a long-running process. 00:12:25.686 --> 00:12:27.576 align:middle It's got a bunch of options if you want it to be... 00:12:27.916 --> 00:12:35.346 align:middle to auto kill after like X time or X hours, etc. But that's the main thing you need to do. 00:12:35.646 --> 00:12:39.146 align:middle And here your handlers are going to be called for every single message. 00:12:39.686 --> 00:12:42.666 align:middle And that's it. 00:12:44.676 --> 00:12:48.876 align:middle That's the one on one of the Symfony Messenger. 00:12:48.876 --> 00:12:55.116 align:middle That's how it works and that's mostly all we want to know about it. 00:12:55.116 --> 00:12:59.896 align:middle Now, I mentioned it's six months already, so I'm going to just do very quick rewind 00:12:59.896 --> 00:13:02.266 align:middle of like what happened and what we changed. 00:13:02.986 --> 00:13:06.176 align:middle So, six months ago Fabien tweeted this things like, yay! 00:13:07.116 --> 00:13:07.746 align:middle We merged it! 00:13:08.016 --> 00:13:12.576 align:middle So probably a year ago I started to create a Symfony Message pull request. 00:13:12.776 --> 00:13:15.886 align:middle We actually broke Github because it was too many comments. 00:13:17.726 --> 00:13:20.086 align:middle And finally somehow it got merged. 00:13:20.266 --> 00:13:20.596 align:middle Super cool. 00:13:20.596 --> 00:13:22.766 align:middle We actually renamed it to Messenger. 00:13:23.216 --> 00:13:26.806 align:middle And the ignorant me was saying: "yay, job's done!". 00:13:26.856 --> 00:13:33.726 align:middle Turns out that actually that was just the beginning of like a lot of work. 00:13:33.936 --> 00:13:35.376 align:middle So since then, so what happened? 00:13:35.376 --> 00:13:38.616 align:middle Very quickly, um, we only had 33 issues. 00:13:39.046 --> 00:13:40.426 align:middle Super cool eh? 00:13:40.726 --> 00:13:41.606 align:middle It worked super well. 00:13:41.606 --> 00:13:46.856 align:middle But we actually had 150 merged pull request in the component. 00:13:47.456 --> 00:13:51.896 align:middle And if you mention the, sort of, not necessarily the pain but the complexity 00:13:51.896 --> 00:13:54.706 align:middle of getting pull requests and the review process and the Symfony code base. 00:13:55.106 --> 00:13:57.326 align:middle That's a lot of work. 00:13:57.946 --> 00:14:03.796 align:middle Out of these pull requests and other kind of side commits, more than a hundred 00:14:03.796 --> 00:14:06.606 align:middle of them were actually for the preparation of 4.1 release. 00:14:07.296 --> 00:14:10.816 align:middle And 91 commits for the release 4.2. 00:14:11.716 --> 00:14:16.696 align:middle Probably out of this 90, 91, is probably 50 of Nicolas 00:14:16.696 --> 00:14:18.656 align:middle because he destroyed the component recently. 00:14:19.296 --> 00:14:23.666 align:middle But the good thing is it's actually coming 00:14:23.666 --> 00:14:26.786 align:middle from 21 different contributors and thank you very much to them. 00:14:27.156 --> 00:14:28.666 align:middle That is the beauty of the... 00:14:28.796 --> 00:14:35.326 align:middle Thank you. 00:14:35.326 --> 00:14:38.716 align:middle That's really the beauty of Symfony I guess is that everybody's just here to make it better. 00:14:38.786 --> 00:14:39.656 align:middle Super cool. 00:14:40.396 --> 00:14:48.956 align:middle So as of a few days ago, it's actually already 100,000 plus downloads. 00:14:48.956 --> 00:14:50.736 align:middle So it's actually been getting used. 00:14:51.066 --> 00:14:55.086 align:middle And now we are actually starting to have much more small tweaks 00:14:55.086 --> 00:14:58.506 align:middle and small features on this component. 00:14:58.566 --> 00:15:01.416 align:middle And I'm going to present three different things that have changed 00:15:01.416 --> 00:15:05.476 align:middle or have been improved in the version 4.2, the new one. 00:15:05.476 --> 00:15:09.586 align:middle The first one is the notion of envelopes. 00:15:09.586 --> 00:15:13.696 align:middle So I didn't talk about it yet and this is the best moment to introduce it. 00:15:14.526 --> 00:15:17.506 align:middle The notion of the envelope is to say, well, you've got your message, 00:15:17.546 --> 00:15:21.716 align:middle we didn't want to put any pressure on your side - do anything special with the messages... 00:15:22.076 --> 00:15:26.266 align:middle although, when we started to go asynchronous, there is a lot of things actually we... 00:15:26.446 --> 00:15:30.806 align:middle that can go wrong and there is a lot of information we actually want to carry around. 00:15:31.326 --> 00:15:36.236 align:middle Well it's the same as the beautiful analogy of the postal message. 00:15:36.556 --> 00:15:38.716 align:middle You wrap that into an envelope and you put a bunch of stamps. 00:15:39.246 --> 00:15:41.896 align:middle That's the exact same thing. 00:15:42.086 --> 00:15:43.766 align:middle We have envelopes within Symfony. 00:15:44.016 --> 00:15:47.866 align:middle It's a PHP object, it contains a message and guess what? 00:15:48.916 --> 00:15:49.766 align:middle It has some stamps. 00:15:50.656 --> 00:15:54.436 align:middle So before there were actually named Items, that's the main thing that we actually renamed 00:15:54.436 --> 00:15:57.716 align:middle to make sure that the analogy makes sense for everybody, but it's really that. 00:15:57.716 --> 00:16:01.126 align:middle So we can mark the envelope with a bunch of information. 00:16:01.736 --> 00:16:03.966 align:middle Built-in within the component, we've got three stamps. 00:16:04.226 --> 00:16:08.556 align:middle We've got the ReceivedStamp, we've got the SentStamp and we've got the HandledStamp. 00:16:09.226 --> 00:16:11.226 align:middle So we can actually know when we get an envelope, 00:16:11.226 --> 00:16:14.126 align:middle we can know whether the message has been received from a transport 00:16:14.126 --> 00:16:18.196 align:middle or actually we just sent it to a transport, or we actually, the handler has been called. 00:16:18.566 --> 00:16:20.786 align:middle That's the main, the really important information. 00:16:21.646 --> 00:16:24.326 align:middle So how we are going to use it? 00:16:25.386 --> 00:16:26.676 align:middle I'm going to show you the... 00:16:27.216 --> 00:16:30.446 align:middle so that's the message, the interface, the main interface you're using. 00:16:30.776 --> 00:16:33.326 align:middle You're going to use every day - the MessageBusInterface. 00:16:33.326 --> 00:16:34.856 align:middle That actually changed in the 4.2. 00:16:35.286 --> 00:16:38.566 align:middle So the main thing is you can dispatch a message. 00:16:39.456 --> 00:16:44.046 align:middle But actually, if you look at the param, param PHP doc, 00:16:44.216 --> 00:16:46.156 align:middle you can dispatch a message or an Envelope. 00:16:47.106 --> 00:16:49.496 align:middle So you can yourself, on your side, create... 00:16:49.756 --> 00:16:55.336 align:middle wrap your own message into an Envelope and add a bunch of stamps, if you want to. 00:16:56.026 --> 00:16:59.136 align:middle But main thing is it actually returns an Envelope now. 00:17:00.046 --> 00:17:06.096 align:middle Before, it was actually returning the return value of the actual message handler. 00:17:07.016 --> 00:17:11.286 align:middle Um, and that guy, Nicolas did... 00:17:11.286 --> 00:17:15.616 align:middle So basically he said, well: Symfony Messenger sounds very interesting, 00:17:15.616 --> 00:17:17.816 align:middle I'm gonna actually look at it. 00:17:18.006 --> 00:17:19.926 align:middle And he found a bunch of things to fix. 00:17:20.386 --> 00:17:25.636 align:middle And one of them was actually a long, long, long, long, long discussion over multiple weeks: 00:17:26.346 --> 00:17:29.726 align:middle how can we manage this return value of the message bus. 00:17:29.726 --> 00:17:31.446 align:middle Beginning was a mixed return value. 00:17:31.846 --> 00:17:35.846 align:middle That sort of made no sense because it's super unpredictable, when you dispatch a message, 00:17:35.846 --> 00:17:37.536 align:middle you don't know what's going to come back. 00:17:37.536 --> 00:17:39.286 align:middle And that is a real problem. 00:17:39.436 --> 00:17:42.676 align:middle So then, we decided to say, okay, let's return the Envelope. 00:17:42.676 --> 00:17:44.696 align:middle And that kind of makes sense. 00:17:44.806 --> 00:17:50.796 align:middle Now by doing that, what you can do is when you dispatch the message, you get the Envelope back. 00:17:50.796 --> 00:17:54.976 align:middle And on the Envelope, you can get a, you've got a bunch of methods. 00:17:55.166 --> 00:17:57.886 align:middle And the one that is used here is the last() method. 00:17:58.336 --> 00:18:02.036 align:middle So you can get the last stamp of a specific type. 00:18:03.936 --> 00:18:09.326 align:middle So first, obviously it implies that we can have multiple stamps of the same type. 00:18:10.156 --> 00:18:16.816 align:middle But the first example is if the last stamp of type SentStamp is not null, 00:18:17.026 --> 00:18:19.876 align:middle well it actually means that we sent the message to the transport. 00:18:20.436 --> 00:18:24.596 align:middle Just right now when we called $bus->dispatch(), it has been sent to a transport. 00:18:25.596 --> 00:18:28.056 align:middle And each stamp contains a bunch of information. 00:18:28.236 --> 00:18:33.936 align:middle The second example is that we actually use the same same thing: 00:18:33.936 --> 00:18:36.886 align:middle we get the last stamp of type HandledStamp. 00:18:38.076 --> 00:18:40.506 align:middle But you actually get the stamp into a $handled variable. 00:18:41.246 --> 00:18:44.076 align:middle And what we can say is that, well, the message has been handled. 00:18:44.416 --> 00:18:46.326 align:middle So a message handler has just been called. 00:18:47.116 --> 00:18:52.026 align:middle And we can, on the stamp, call the getResult() method to get much more information. 00:18:52.026 --> 00:18:54.216 align:middle So we can get the result of the handler. 00:18:54.516 --> 00:18:59.066 align:middle Actually, because multiple handlers can be called, you can have multiple HandledStamp 00:18:59.236 --> 00:19:03.046 align:middle and then you can get all the results. 00:19:03.046 --> 00:19:05.546 align:middle Same idea for if you send it to multiple transport 00:19:05.546 --> 00:19:08.846 align:middle at the same time, you can have multiple SentStamp. 00:19:10.076 --> 00:19:15.456 align:middle So that's how you would use the Envelope within your code base. 00:19:17.056 --> 00:19:20.786 align:middle That's the advanced track. 00:19:20.786 --> 00:19:24.736 align:middle So the stamps themselves, they are automatically added, they are added by the Symfony Messenger - 00:19:24.736 --> 00:19:26.286 align:middle the few of them that I've mentioned. 00:19:26.836 --> 00:19:28.856 align:middle Now, you can very easily create your own. 00:19:28.856 --> 00:19:33.966 align:middle So you can just create a class, implement the empty StampInterface and create your own thing. 00:19:34.236 --> 00:19:38.336 align:middle So you can carry much more information if you want to have a unique identifier 00:19:38.336 --> 00:19:41.176 align:middle for that message, then you can carry it across your application. 00:19:42.016 --> 00:19:42.546 align:middle That you can do. 00:19:42.756 --> 00:19:46.726 align:middle If you want to carry the user context, you can completely do that outside of the message. 00:19:46.726 --> 00:19:48.136 align:middle You can carry much more information. 00:19:48.556 --> 00:19:55.396 align:middle And the very important thing is the stamps will survive the serialization. 00:19:55.926 --> 00:19:59.306 align:middle So that's, so if when you start to do asynchronous processing, 00:20:00.016 --> 00:20:04.066 align:middle that's where the real troubles comes in, is the serialization process. 00:20:04.716 --> 00:20:07.496 align:middle So your message, your php class, when it's within the php memory, 00:20:07.496 --> 00:20:10.296 align:middle super cool, we can put whatever we want. 00:20:10.966 --> 00:20:17.386 align:middle Now, if we want it to be consumed by another php binary somewhere else, we need to serialize it. 00:20:17.436 --> 00:20:21.996 align:middle We need to put it in a way so that we can put it somewhere as a string 00:20:22.626 --> 00:20:26.616 align:middle and deserialize it into the other php process. 00:20:27.336 --> 00:20:31.046 align:middle So these stamps are going via the serialization process. 00:20:32.006 --> 00:20:39.016 align:middle So very quickly, that's the detail of the AMQP transport, the default serialization, 00:20:39.556 --> 00:20:41.186 align:middle or the way your message is actually sent, 00:20:41.516 --> 00:20:46.156 align:middle is using the Symfony Serializer using the JSON format. 00:20:47.096 --> 00:20:52.386 align:middle So that is how a message would look like within the RabbitMQ. 00:20:52.896 --> 00:20:55.046 align:middle This payload is literally just your message. 00:20:55.246 --> 00:20:57.046 align:middle So within the payload of... 00:20:57.246 --> 00:21:01.646 align:middle which is in the message of RabbitMQ is just your thing with no constraints. 00:21:01.646 --> 00:21:04.106 align:middle No Symfony, neither php related things. 00:21:04.236 --> 00:21:08.506 align:middle So what it means that you can very easily use the messenger to also communicate 00:21:08.506 --> 00:21:11.486 align:middle with the other types of systems, other language, other frameworks. 00:21:12.256 --> 00:21:16.466 align:middle Now, to carry a bit more information, we use the headers. 00:21:16.616 --> 00:21:21.576 align:middle So we basically put the type of the header to add the type header, to say, 00:21:21.576 --> 00:21:26.416 align:middle well that is the type of message, so we can deserialize the right class. 00:21:26.926 --> 00:21:27.856 align:middle And also we can... 00:21:28.166 --> 00:21:30.746 align:middle another set of headers for each stamp. 00:21:31.266 --> 00:21:33.816 align:middle That's how we carry this information. 00:21:39.086 --> 00:21:42.756 align:middle Very, very related: the second concept is the concept of middleware. 00:21:42.906 --> 00:21:48.236 align:middle And actually there's a moment where I said that the message bus itself, the class MessageBus, 00:21:48.386 --> 00:21:50.926 align:middle which is the only implementation of the MessageBusInterface, 00:21:51.416 --> 00:21:54.816 align:middle is I think it's 10 lines of useful code. 00:21:55.236 --> 00:21:57.376 align:middle The rest is just comments and stuff like that. 00:21:58.266 --> 00:22:01.206 align:middle The real logic of every single bus actually comes from the middleware. 00:22:02.546 --> 00:22:05.006 align:middle I cannot say middlewares because in english we don't say that, 00:22:05.006 --> 00:22:07.216 align:middle it's just middleware, there is no plural apparently. 00:22:07.736 --> 00:22:11.266 align:middle So that's the middleware, multiple of them. 00:22:11.546 --> 00:22:13.586 align:middle You may have seen this kind of stuff. 00:22:13.746 --> 00:22:21.636 align:middle Um, that's the graph that comes from CakePHP that describes how they use middleware, 00:22:21.636 --> 00:22:27.496 align:middle the middleware mechanism to handle the request and the response, the HTTP request and response. 00:22:27.736 --> 00:22:31.706 align:middle The idea is very simple: every single middleware is in a stack. 00:22:32.476 --> 00:22:34.866 align:middle So there is an ordered list of middleware 00:22:35.106 --> 00:22:37.186 align:middle and each middleware is responsible for calling the next one. 00:22:37.486 --> 00:22:41.116 align:middle And they can do specific actions before or after. 00:22:42.506 --> 00:22:45.826 align:middle The Symfony Messenger bus as the exact same way of working. 00:22:46.296 --> 00:22:50.376 align:middle So there is our middleware, the Symfony Messenger one, 00:22:50.826 --> 00:22:53.356 align:middle and there are two main important middleware. 00:22:54.266 --> 00:22:54.926 align:middle The two or... 00:22:54.926 --> 00:22:56.066 align:middle the two in the middle. 00:22:56.896 --> 00:22:59.226 align:middle The first one, which is basically because... 00:22:59.226 --> 00:23:02.166 align:middle the one in the middle, the last of the stack, 00:23:02.166 --> 00:23:05.186 align:middle so the last to be called is the HandleMessageMiddleware. 00:23:05.596 --> 00:23:09.226 align:middle So that's the middleware that's responsible of saying: okay, I got this message, 00:23:09.696 --> 00:23:15.236 align:middle I am going to find out which handlers are registered for this message and call them. 00:23:16.596 --> 00:23:20.346 align:middle There is a middleware above that, which is SendMessageMiddleware. 00:23:20.496 --> 00:23:23.346 align:middle And this middleware is responsible for sending the message to a transport. 00:23:23.346 --> 00:23:27.576 align:middle So if this middleware decide that, well I need to send the message to a transport, 00:23:28.466 --> 00:23:32.506 align:middle it won't call the handle message middleware: it will just return the Envelope. 00:23:33.336 --> 00:23:40.366 align:middle So the entire behavior of a message bus is actually within the middleware. 00:23:40.476 --> 00:23:41.446 align:middle And you can create your own. 00:23:41.956 --> 00:23:47.076 align:middle So in order to create your own, that's just a class that implements a MiddlewareInterface. 00:23:48.146 --> 00:23:49.186 align:middle It has just one method. 00:23:49.376 --> 00:23:55.566 align:middle I kind of mentioned it: it takes as an input an Envelope, and as an output another Envelope. 00:23:56.116 --> 00:24:02.426 align:middle It also takes the stack as - the middleware stack as an argument 00:24:02.426 --> 00:24:03.856 align:middle so that it can call the next one. 00:24:04.386 --> 00:24:09.436 align:middle So an empty middleware that's is completely transparent, will look like that. 00:24:09.846 --> 00:24:13.866 align:middle The main thing is return stack: from the stack and get the next middleware, 00:24:13.866 --> 00:24:15.116 align:middle and call the handle method again. 00:24:15.526 --> 00:24:17.096 align:middle I just call the next middleware. 00:24:17.436 --> 00:24:22.166 align:middle And here, I can actually add some behavior, I can add some things, things that are going 00:24:22.166 --> 00:24:25.216 align:middle to happen before and some things that are going to have to happen after. 00:24:25.386 --> 00:24:26.566 align:middle After what? 00:24:26.566 --> 00:24:27.626 align:middle Or before what? 00:24:27.626 --> 00:24:29.956 align:middle After and before the next middleware. 00:24:30.456 --> 00:24:35.986 align:middle And if you look at the previous slide, it actually means it is going 00:24:36.436 --> 00:24:40.496 align:middle to be running something before or after either the message has been sent 00:24:40.496 --> 00:24:41.676 align:middle or the message has been handled.... 00:24:42.266 --> 00:24:45.366 align:middle your message handler has been called. 00:24:45.946 --> 00:24:52.516 align:middle Yep? So, I'm gonna show you an example middleware, and I'll walk you through. 00:24:53.556 --> 00:24:56.466 align:middle The main thing here is that line at the bottom, 00:24:56.716 --> 00:24:58.786 align:middle which return is, return $stack->next()->handle(). 00:24:59.236 --> 00:25:01.666 align:middle That's super important: as a middleware, I need to call the next ones. 00:25:02.186 --> 00:25:06.056 align:middle Here, the concept is to say: well, I can create a middleware that's responsible 00:25:06.096 --> 00:25:10.426 align:middle of auditing what are the commands or what are the messages that went through. 00:25:11.776 --> 00:25:15.606 align:middle So the first thing that I'm going to do is to get the message from the envelope. 00:25:15.996 --> 00:25:17.216 align:middle So that's your php class. 00:25:17.626 --> 00:25:21.226 align:middle Get the message so that after, I can display a bunch of messages 00:25:21.526 --> 00:25:23.026 align:middle that contains the class of the message. 00:25:23.136 --> 00:25:27.856 align:middle So it's going to say: well, either I received the message or I started to dispatch a message. 00:25:28.466 --> 00:25:33.306 align:middle To get the class at the end of the line, just get the class of the message. 00:25:34.876 --> 00:25:39.156 align:middle Now there is one thing that if - and you've seen that already with the two other stamps, 00:25:39.316 --> 00:25:43.576 align:middle but it's the same mechanism here - if from the envelope we've got the stamp 00:25:43.576 --> 00:25:47.966 align:middle that says ReceivedStamp, it actually means that we are in the consumer. 00:25:48.256 --> 00:25:51.826 align:middle We are under, bin/console messenger:consume-messages side. 00:25:51.826 --> 00:25:55.706 align:middle So in the logs, I won't put a "started with message", I would just put, like, 00:25:55.806 --> 00:25:59.416 align:middle "received message" because that's the context. 00:25:59.836 --> 00:26:04.996 align:middle So when you look at your log a few days later or something, 00:26:05.216 --> 00:26:10.236 align:middle the future you will actually thank you very much - that you didn't put the same message 00:26:10.236 --> 00:26:12.406 align:middle and that you don't know when things have happened. 00:26:12.876 --> 00:26:16.416 align:middle We don't know exactly, um, what was the context of the message execution. 00:26:16.856 --> 00:26:22.036 align:middle Because the middleware they were called when we received the message from the transports or, 00:26:22.036 --> 00:26:24.486 align:middle when we actually dispatched it from the web application. 00:26:25.016 --> 00:26:35.136 align:middle Because the messages all the time go from the bus. 00:26:35.136 --> 00:26:38.346 align:middle Now, there is this notion of stamps and this custom stamp. 00:26:38.346 --> 00:26:42.486 align:middle So here is a simple example where you can create your custom stamp - 00:26:42.576 --> 00:26:44.266 align:middle here I have named it AuditStamp. 00:26:45.086 --> 00:26:47.076 align:middle It will just contain an identifier. 00:26:47.076 --> 00:26:50.906 align:middle So we can actually stick an identifier to this given specific envelope, 00:26:50.906 --> 00:26:55.846 align:middle and you can stick this identifier so that in your log you can correlate the log 00:26:55.846 --> 00:27:00.286 align:middle that have happened on the web server: when you created the message, when you dispatch 00:27:00.286 --> 00:27:04.846 align:middle and send the message and the logs that are happening in the CLI, in the background process, 00:27:05.776 --> 00:27:08.526 align:middle because you're going to have the same identifier for this specific message. 00:27:09.186 --> 00:27:12.296 align:middle Because this stamp, if it doesn't exist - that's the first line - 00:27:12.346 --> 00:27:17.146 align:middle if the AuditStamp does not exist, you add the stamp on the envelope. 00:27:18.086 --> 00:27:23.626 align:middle And because these stamps are like, carried around with the serialization process, 00:27:24.436 --> 00:27:26.686 align:middle you're going to have your AuditStamp when you consume the message. 00:27:32.156 --> 00:27:33.786 align:middle And that's this middleware. 00:27:34.306 --> 00:27:38.106 align:middle So this notion of stamps and envelopes - coupled with the middleware - 00:27:38.106 --> 00:27:44.576 align:middle in my perspective are super, super valuable because we can do such things. 00:27:44.756 --> 00:27:50.656 align:middle When you create your own middleware, well the only thing you need to do is to register it. 00:27:50.806 --> 00:27:55.716 align:middle So you need to explicitly say this bus is going to have this middleware. 00:27:56.056 --> 00:27:59.556 align:middle This example is saying you can create multiple buses, 00:27:59.556 --> 00:28:02.306 align:middle this is just an example of creating multiple buses. 00:28:02.306 --> 00:28:07.196 align:middle And here one of them that we called command_bus will have this AuditMiddleware 00:28:07.196 --> 00:28:08.446 align:middle that we've created. 00:28:10.096 --> 00:28:12.546 align:middle So every message that we dispatch into this command_bus, 00:28:12.856 --> 00:28:14.836 align:middle will go through our new AuditMiddleware. 00:28:15.316 --> 00:28:21.666 align:middle while the rest, or if the message is going to the event_bus, won't go through this middleware. 00:28:22.396 --> 00:28:26.866 align:middle That's an example a bit more complex because we've got multiple buses, but imagine 00:28:26.866 --> 00:28:30.996 align:middle and replace, just remove the event_bus and that's the normal behavior 00:28:30.996 --> 00:28:32.776 align:middle of just having one bus in your Symfony application. 00:28:33.346 --> 00:28:40.166 align:middle Now there's just a small clarification: the stack. 00:28:40.486 --> 00:28:43.736 align:middle Because that's the main thing as well that's changed in the MiddlewareInterface. 00:28:44.726 --> 00:28:47.446 align:middle Before we had a sort of magic second parameter. 00:28:47.446 --> 00:28:48.906 align:middle Instead of the stack, there was "next", 00:28:48.906 --> 00:28:52.746 align:middle so we could just call $next() parenthesis and call the next middleware. 00:28:53.476 --> 00:28:57.356 align:middle Well the problem was, by doing that, the next, 00:28:57.666 --> 00:29:03.446 align:middle the function that was behind the next variable was actually within the message bus class. 00:29:03.746 --> 00:29:07.286 align:middle So what it meant is that the stack trace was super, super horrible. 00:29:07.286 --> 00:29:10.336 align:middle And if you're using a profiler or something like that, 00:29:10.796 --> 00:29:13.426 align:middle you will always see the middleware going back to the message bus, 00:29:13.426 --> 00:29:18.056 align:middle going back to the next middleware, etc, etc. That way it's actually much more explicit 00:29:18.056 --> 00:29:22.746 align:middle as well: you get the stack and you get directly the next middleware within your own middleware. 00:29:23.556 --> 00:29:26.296 align:middle So you just go: $nextMiddleware->handle() and that's it. 00:29:27.296 --> 00:29:28.886 align:middle It directly called the next middleware. 00:29:29.046 --> 00:29:32.626 align:middle The stack trace is very good or very simple when you get exceptions. 00:29:33.176 --> 00:29:34.546 align:middle And that's very useful. 00:29:34.546 --> 00:29:42.416 align:middle So that's the sort of, um, details of what's changed and how, about the middleware. 00:29:43.186 --> 00:29:48.916 align:middle Now, the last thing I want to talk about quickly are the transports. 00:29:49.586 --> 00:29:53.816 align:middle The first thing, again, and I think it's really important to reiterate that, 00:29:53.816 --> 00:29:57.516 align:middle is that you don't need transports to benefit from the Messenger component. 00:29:58.696 --> 00:30:04.256 align:middle By itself, the structure that it offers you is really interesting for you to use. 00:30:04.346 --> 00:30:05.616 align:middle So we don't need transports. 00:30:06.096 --> 00:30:10.986 align:middle And I think it's been built in a way so that we can have very nice or an easy migration path. 00:30:11.216 --> 00:30:13.206 align:middle As in, we do synchronous as much as possible. 00:30:13.206 --> 00:30:18.496 align:middle The reason is, asynchronous, for a lot of reasons, including the fact 00:30:18.496 --> 00:30:23.426 align:middle that you might have inconsistencies between when you run the message 00:30:23.426 --> 00:30:29.376 align:middle and when the message has been dispatched, with the fact that you may have something 00:30:29.466 --> 00:30:33.936 align:middle that actually needs to return the value from the synchronous background process. 00:30:33.936 --> 00:30:37.946 align:middle We need to have sort of like asynchronous notifications via email or whatever. 00:30:37.946 --> 00:30:39.826 align:middle There is much more complexity. 00:30:40.386 --> 00:30:41.976 align:middle So you can start synchronous. 00:30:42.296 --> 00:30:46.276 align:middle And then you can configure the transport and then you can write a message to be asynchronous. 00:30:46.386 --> 00:30:50.436 align:middle That is sort of like the great path, as has been planned. 00:30:51.576 --> 00:30:55.206 align:middle So the transport, we have a built-in AMQP transport. 00:30:55.776 --> 00:30:59.456 align:middle So if you've got, the um, the only requirement is the AMQP php extension. 00:31:00.416 --> 00:31:04.606 align:middle If you've got that, you can actually directly use RabbitMQ, and that's it. 00:31:05.056 --> 00:31:13.046 align:middle Now there is an amazing php library is called Enqueue , which has 1+ transports. 00:31:13.286 --> 00:31:20.216 align:middle So if you're using AWS, SQS transport, if you are using google, you've got Google Pub/Sub, 00:31:20.476 --> 00:31:25.576 align:middle so using more exotic things like Kafka, you can actually use them. 00:31:26.116 --> 00:31:28.976 align:middle Even just a file as well, this kind of stuff. 00:31:28.976 --> 00:31:31.956 align:middle There is an integration with Enqueue there is an adapter 00:31:31.956 --> 00:31:35.476 align:middle so that you can directly create using the EnqueueBundle all these transports 00:31:35.816 --> 00:31:38.016 align:middle and use them directly in the messenger. 00:31:38.016 --> 00:31:41.586 align:middle So you can directly route the messages to an Enqueue transport. 00:31:42.086 --> 00:31:48.276 align:middle So it means that already right now you've got dozens of actually transport you can use. 00:31:49.526 --> 00:31:52.246 align:middle One thing that we changed, which is very important for you if you want 00:31:52.246 --> 00:31:55.166 align:middle to create transports, is that we simplified the serialization. 00:31:55.616 --> 00:31:57.986 align:middle Before we had the notion of encoder and decoder. 00:31:58.346 --> 00:31:59.686 align:middle Now it's very simple. 00:31:59.776 --> 00:32:04.276 align:middle You've got just one class, that is responsible of serializing and unserializing the messages. 00:32:05.926 --> 00:32:11.936 align:middle You can, so I mentioned by default, using Symfony Serializer, if you want to use protobuf, 00:32:11.936 --> 00:32:15.366 align:middle if you want to use csv, you can easily create a class 00:32:15.366 --> 00:32:20.016 align:middle that implements the SerializerInterface and roll your own. 00:32:22.666 --> 00:32:24.666 align:middle So what about now? 00:32:25.206 --> 00:32:29.016 align:middle So now the Symfony Messenger component, it's still experimental in 4.2. 00:32:30.396 --> 00:32:36.546 align:middle So what it means is that maybe in 4.3 we're going to change things as well. 00:32:37.036 --> 00:32:40.876 align:middle So the idea is to say for new components, because we - and especially this one 00:32:40.876 --> 00:32:43.456 align:middle which touches more than the scope of just the php process - 00:32:43.456 --> 00:32:46.266 align:middle there was potentially things we didn't see coming. 00:32:46.596 --> 00:32:51.156 align:middle And maybe there are design or structure in the component that we need to tweak 00:32:51.606 --> 00:32:53.236 align:middle to make sure you actually benefit for everybody. 00:32:53.596 --> 00:32:58.836 align:middle I think it's very unlikely, but it might change from 4.2 to 4.3. 00:32:59.216 --> 00:33:05.336 align:middle It doesn't mean that it is not usable, it just means that if you, when you will upgrade 00:33:05.336 --> 00:33:09.626 align:middle from 4.2 to 4.3, you might have some slight things to change. 00:33:13.546 --> 00:33:15.306 align:middle It is much better than before. 00:33:15.306 --> 00:33:20.126 align:middle And really I think the massive work of the community has been great 00:33:20.126 --> 00:33:22.366 align:middle in a way that: it's super easier. 00:33:22.366 --> 00:33:27.966 align:middle The error messages are like, make much more sense, and you've got this notion of stamps 00:33:27.966 --> 00:33:31.866 align:middle that actually to me seems very, very simple to grasp. 00:33:33.166 --> 00:33:36.866 align:middle Now, the documentation deserves a lot more love. 00:33:37.026 --> 00:33:42.636 align:middle It's a super hard problem, especially for components moving super fast like this one. 00:33:42.676 --> 00:33:50.506 align:middle If you feel you can help, that's an amazing contribution to do, 00:33:50.506 --> 00:33:59.196 align:middle and it will help a lot of people. 00:33:59.196 --> 00:34:00.316 align:middle So on that. 00:34:00.316 --> 00:34:02.036 align:middle Thank you very much.