A regular meet up brought together the teams of PHP developers. Google had inspired the discussion by having introduced the library for transmitting structured data - Protocol Buffers (protobuf). This protocol is being actively used in one of the Noveo projects, but, as it turned out, the participants did still learn something new. A little insight into the matter – how to transmit data and a survey of some alternative solutions – brought everyone up to date in order to stay on the same page. It is not worth digging into the issue as there are so many options fitting every taste. However, even a superficial glance at the competitors may work to one’s advantage and help find the way around the ready-made solutions and propose the best option for a customer.
Among the top three, compared to Protocol Buffers, there is Apache Thrift, for instance, the product developed and used by and large by Facebook. It should be definitely taken into consideration as, like protobuf, it can describe variables of request/response messages and yet design API, cross platform API. Message Pack is not losing its ground, “it’s like JSON but fast and small” they claim and it is true. If you are used to JSON but don’t think much of the overhead from such “monsters” as Thrift and Protobuf then Massage Pack can be just the job. And, of course, let’s not forget about the PHP potential, which is itself well-suited for data interchange because json_encode/json_decode is still there.
Then we headed to learn more about the meet up causer – the library Protocol Buffers. We addressed the issue of the syntaxes. Despite being quiet simple you still need some time to get used to the new key words. Moreover, currently there are two active versions of the library so it was important to point out the differences and the possibilities the new third version Protocol Buffers offers. In fact there are just three of them. First of all, if you need to use the third version protobuf then at the beginning of the file with a description add syntax = “proto3”
to the service otherwise the second version is used as a default. Second of all, the Protobuf developers decided that validation had nothing to do with the data interchange and so they removed the key words optional and required which were mandatory in proto2. Now clients have to validate requests and responses themselves in order to check if all the required fields are complete. However, the main difference is that the new version protobuf can (and even has to, as it is what it has been created for) describe not only a message format but also the used methods. In such a way it describes the whole structure of the application which will be actually used by clients.
Some might need examples to process information especially when speaking about new syntaxes. That is why the presentation was full of a bit unrealistic examples which really work though. So creating a message seems to be very easy: $message = new MessageRequest()
; or you can just send a data array in a constructor right away and the created object will contain all necessary values. Later you can change one specific field - $message->setFieldName(true)
; but protobuf opens up its potential when it comes to data serialization. Being a binary data communication protocol it allows to save up to 60% of traffic. So a JSON-line of 64 figures contracts to 17.
In the title of the meet up we mentioned how to connect Protocol Buffers and Symfony for a reason. In the end there was a presentation of a real-life application that used almost everything from the presentation but filtered by Symfony framework. Namely, how to create a service, forward a request from a controller to the service, process it and send back. And above all, how a received response makes a valid JSON to pass it on to a client.
Modesty aside, Protocol Buffers 3 is in fact an ideal solution for development of middle and large applications. This library provides a powerful box tool to design applications and describe how clients interact with the server. Convenient and readable syntaxes of proto-files is simple and straightforward, and a native compiler lets generate ready-made files for the most languages - PHP, JS, TypeScript, Go etc. All of that and a little Symfony magic – the listener converting requests into a protobuf-request and the controller result handler for receiving protobuf-response allow to create a really simple scalable application with business logic and framework-independent.