Five reasons to use Protocol buffers instead of JSON

In Ruby and Rails developers, the service-oriented (service-oriented) architecture has a well-deserved reputation as a powerful way to mitigate the vicious growth of program size and to extract concerns in a large number of applications. These new, compact services typically continue to use rails or Sinatra and use JSON to communicate over HTTP. Although JSON as a data interchange format, there are many advantages: human readable, understandable, and usually perform well.

Browsers and JS do not process data directly-especially when internal services are encountered. My point is that structured formats, such as Google's protocol buffers, are a better coding option than JSON. If you have never used protocol buffers, you can see here. Don't worry, this article describes how to use it on Ruby before explaining why you should choose Protocol buffers instead of JSON.

a brief introduction to Protocal buffers

First of all, what is protocol buffers? The document says:

"Protocol buffers is a way to encode structured data in an efficient and extensible format. ”

Google has developed protocol buffers to use in-house services. It is a binary format that allows you to define a pattern using the canonical language, for example:

?

12345

message Person {  required int32 id = 1;  required string name = 2;  optional string email = 3;}

You can encapsulate them in the namespace or declare them in the top-level way. This fragment defines the pattern for the person data type, with three fields: ID, name, and email. In addition to naming fields, you can provide a type that determines how data is encoded and sent online, where we see Int32 types and String types. Keywords are also provided for validation and structuring (required and optional). Fields are numbered, which helps backwards compatibility, which I'll describe in more detail later.

The Protocol buffers specification has been implemented in several languages: Java,c,go and so on. If you look around for the most modern language there is a way to achieve it. Ruby is no exception, there are several different gems that use protocol buffers to encode and decode data. This means that the specification can pass data between systems implemented in different languages.

For example, the Ruby gem installation, known as RUBY-PROTOC, can be used in combination with the main protocol buffers library (brew install PROTOBUF in OSX), which automatically generates piles of files for encoding and decoding data. A running binary proto file produces the following Ruby classes:

?

1234567891011121314

#!/usr/bin/env ruby# Generated by the protocol buffer compiler. DO NOT EDIT!require ‘protocol_buffers‘# forward declarationsclassPerson < ::ProtocolBuffers::Message; end     classPerson < ::ProtocolBuffers::Message  set_fully_qualified_name "Person"        required :int32, :id, 1  required :string, :name, 2  optional :string, :email, 3end

As you can see, by supporting this pattern (Protocol buffer format) to encode and decode information, we get a class automatically (see the base class for code protocolbuffers::message for more details on the gem). We've seen some of the information, so let's take a closer look at these feature points and let me try to persuade you to consider protocol buffers--here are 5 reasons.

Cause #1: The pattern itself is very good

There is a painful irony pointing to the fact that we carefully write the data model in our database, maintain all levels of code, keep these data models in control, and when we want to send data to another service, ask that all doubts be taken into account. However, we tend to rely on code that is inconsistent between our systems on the boundary and our system does not enforce the structuring of our data components, which is so important that the encoding semantics are the business objects that you used to be, in the proto format, it is enough to help and ensure that the signals between applications are not lost, And the boundaries are the business rules that you create and execute.

Cause #2: backwards compatible for free

The numbered field excludes the required version check in the definition of Proto, which is one of the explicitly stated motives (why design and implement protocol buffers). As stated in the developer documentation, the protocol is designed to prevent, to some extent, "ugly code" like the following, which is used to detect the version of the Protocol:

?

12345678

if(version == 3) {  ...} elseif (version > 4) {  if(version == 5) {    ...  }  ...}

As with the numbered fields, you have to change your coding habits to change in the direction that you can maintain and backward-compatible with older versions. As stated in the documentation, once Protocol buffers was introduced like this:

"New fields can be easily introduced, and there is no need for intermediate services to examine the data to be parsed, without having to know all the fields through the data." ”

Servers that have already deployed a variety of JSON have been exposed to a variety of issues related to development patterns and backwards compatibility. I now believe that the numbering field can prevent errors and simplify the rollout of new features and services.

Cause #3: Less Sample code

In addition to explicit version checking and lack of subsequent compatibility, the basic service of the JSON terminal on HTTP usually relies on specialized handwriting boilerplate code to handle the encoding and decoding of Ruby objects. Parsing and anti-parsing classes often contain hidden business logic, which exposes a flaw in manually parsing each new data type, and when a class is produced by protocol buffers (you don't normally touch it), it provides a lot of similar methods and avoids a lot of headaches. As the pattern progresses, you will generate classes with proto (it should be admitted that once you update them), you can leave more space for the challenges you are focusing on (keeping your app running and building the product continuously).

Cause #4: Validation and extensibility

The required,optional and repeated keywords are very powerful in the definition of protocol buffers. They allow you to encode, at the pattern level, visualize your data structures and to implement the details of how classes work (each programming language is processed). Ruby's Protocol_buffers library will raise exceptions, such as if an object instance does not fill in the required fields, and you try to encode such an object instance, it will raise the exception. By simply editing the value of a new numbered field, you can change a field from required to optional or vice versa. With this flexible encoding of the semantic serialization format, it greatly enhanced its functionality.

Because you can also embed proto, define the other members of the internal, you can also have a common request and response structure, it also allows the transmission of other data structures and ensure the transmission connection, it provides a real flexibility for inter-server communication and secure data transmission opportunities. A database system like Riak uses protocol buffers has great effects-because of some revelations, I suggest revisiting those interfaces.

Reason # #: Recommended Language Interoperability

Because protocol buffers has been implemented in multiple languages, interoperability between multi-language mixed applications in your architecture has become simpler. If you introduce a new service in Java or go, and even back-end communication with node or Clojure or Scala, you simply give the proto file to the code generator in the target language, and you'll get better security and interoperability between these architectures. The details of the platform-specific data types are processed by the target language, and you will be more concerned with the difficult parts of your problem, rather than matching fields and data types in the JSON encoding and decoding scheme.

when would it be more appropriate to use JSON?

Sometimes JSON is more appropriate than protocol buffers, including the following scenarios:

• You need or want the data to be readable to people.

• Data from the service is sent directly to the Web browser

• Your server-side application is written in JavaScript

• You're not going to bind the data model to the pattern.

• You don't have the bandwidth to add another tool to your armory.

• Operational burden of running different types of network services

There may be more. Finally, in short, it is important to weigh in mind and not blindly choose a technology

Conclusion

Protocol buffers provides several compelling advantages of relative JSON to transmit data online between internal services. Without completely replacing JSON, especially in the case of direct communication between services and Web browsers, Protocol buffers offers a real advantage not only in the methods outlined above, but also in the speed and data size of codecs.

What services can you extract from your application? If you had to make a choice today, would you choose JSON or protocol buffers? Let's discuss the discussion-we would like to hear more about your experience with JSON and protocol buffers in the comments below.