Overview

REST is an architectural style built on top of HTTP/1. GRPC is not a style instead it is an RPC framework built on top of HTTP/2 and it uses protocol buffers behind the scenes. So basically GRPC is an actual implementation or you can say it is a library whereas REST is just a set of rules and principles.

Although we are comparing a GRPC (implemented framework) with REST -( architectural styles and principles), which might sound weird. Still, it is important to understand the difference in terms of high-level architecture which you will get if you follow one approach over the other

Here are the major differences between the two. Also to mention that this article assumes that you already have some knowledge of GRPC, HTTP2, REST

Links

GRPC

Here is the link to GRPC for further reading https://grpc.io/

REST

Here is the link to REST for further reading – https://en.wikipedia.org/wiki/Representational_state_transfer

Protocol

• GRPC is an RPC framework and is built on top of HTTP/2

• REST architectural style is specified on top of HTTP/1. All the semantics of HTTP/1.1 has been retained in HTTP/2. So REST APIs should continue to work even one using HTTP/2

Nature

• The way of thinking in GRPC is API-oriented or action-oriented. 

• REST is resource-oriented.

Mode of Data Transfer

• GRPC supports only Protocol Buffers to transfer data between server and client.

• REST supports JSON,  XML, and other data formats.  REST can also be made to work with Protocol Buffers trivially.

Model

• GRPC provides four different ways of communication between client and server. The four different ways are unary, server streaming, client streaming, and bi-directional streaming. So effectively in GRPC both client and server can talk to each other.
  • Unary – This is the simplest one. The clients send a request and the server sends the response
  • Client streaming – The client can send a stream of multiple messages while the server is expected to return only a single response to all client requests.
  • Server Streaming- The client will send only one message while the server can send a stream of messages back to it.
  • Bi-directional streaming – Both client and server can stream multiple messages. The streaming will be in parallel and with no order. Also, it will be nonblocking. Neither client nor server needs to wait for a response before sending the next message.

• REST works on the Request-Response model. Basically, you send the request and then you get the response. So REST only provides a unary way of communication. In REST only the client talks to the server.

Performance

• Since GRPC inherently uses HTTP/2 so all the performance optimizations applied to HTTP/2 automatically are available in GRPC. HTTP/2 has introduced several performance optimizations over HTTP/1 such as
  • Duplex Streaming
  • Multiplexing
  • Headers Compression
  • etc

        Plus GRPC uses protocol buffers internally and since protocol buffers are binary data and have less size, they are transferred over a network fast. GRPC can utilize each TCP connection very effectively.Due to these two reasons, GRPC is very fast.

• REST over HTTP/1 will be slower than GRPC. It uses JSON, XML which for representing the same data take more size than protocol buffers.

Code Generation

• Since GRPC is built on top of protocol buffers it provides automatic code generation. In fact with protocol buffers code generation is a must thing to use GRPC.

• REST also provides code generation through Swagger, OPEN API but that is just an extra thing provided and it is not as effective as code generation by protocol buffers

Type Safety

• Since protocol buffers are used for code generation in the case of GRPC.  So that in a way provides type safety to GRPC. GRPC will not allow you to send int for a field where a string is expected. The API contract is defined by the proto file and is strict.

• REST doesn’t have any such restriction. The API contract is mostly just a document using OPEN API or swagger and hence it is loose.

SetUP

• GRPC would require you to set up a client locally to be able to make a GRPC call.

• REST call doesn’t need a client set up. You can make a call using a browser, postman, curl, etc

When To Use

• GRPC is mostly suitable for internal microservices where low latency and high throughput might be needed. It will not be suitable to currently expose your service as a GRPC as there are no APIs available for external services to integrate. It could be possible in the near future when GRPC is fully evolved.

• REST is more suitable to expose your APIs to external services.

Conclusion

These are some of the major differences between GRPC and REST. Hope you have liked this article. Please share feedback in the comments.

Note: If you are interested in learning Golang, then for that we have a golang comprehensive tutorial series. Do check it out – Golang Comprehensive Tutorial Series

The post Difference between GRPC and Rest appeared first on Welcome To Golang By Example.

What is Protocol Buffer

Protocol Buffers are data format which stores data in a structured format. Data in the protocol buffer format can be serialized and deserialized by multiple languages.

Sounds Confusing. You can think it on lines of JSON, XML but it has loads of advantages to offer. Still confusing? then don’t worry as we go along the tutorial we will understand why even a new data format is even needed.

Let’s see first with an example of the simplest protocol buffer file.

person.proto

syntax = "proto3";

message Person {
    string name = 1;
}

A couple of points to note about the above file.

• This file is just a blueprint of how our Protocol Buffer structure is. There is no data associated yet. This is different from JSON/XML , in which file also represents the actual data.
• In the above file there is a person message with a field name of type string.  “proto3” means that the message written is incompatible with Protocol Buffer version three.  
• From the above example, there is one difference you can notice from JSON i.e, it has type information. This type of information will be useful in the auto-generation of code in different languages. Let’s see an example of  auto-generation in Golang

Auto Generation of GO Code:

• We can generate a corresponding Golang code using the above person.proto file. But to do that we need to do some installations:

Installations:

• First install the C++ implementation of Protocol Buffers. Each platform has its own way of installation. See this link – https://github.com/protocolbuffers/protobuf/blob/master/src/README.md
• Install Golang
• Install protoc-gen-go – go get -u github.com/golang/protobuf/protoc-gen-go . This package will be used for auto generation of Go code

After the installation is done then cd to the directory which contains the person.proto file. Run this command:

protoc -I ./ --go_out=./ ./person.proto

It will generate a data access go file with name person.pb.go  in the same directory. 

// Code generated by protoc-gen-go. DO NOT EDIT.
// source: person.proto


package person


import (
    fmt "fmt"
    proto "github.com/golang/protobuf/proto"
    math "math"
)


// Reference imports to suppress errors if they are not otherwise used.
var _ = proto.Marshal
var _ = fmt.Errorf
var _ = math.Inf




// This is a compile-time assertion to ensure that this generated file
// is compatible with the proto package it is being compiled against.
// A compilation error at this line likely means your copy of the
// proto package needs to be updated.
const _ = proto.ProtoPackageIsVersion3 // please upgrade the proto package


type Person struct {
    Name                 string   `protobuf:"bytes,1,opt,name=name,proto3" json:"name,omitempty"`
    XXX_NoUnkeyedLiteral struct{} `json:"-"`
    XXX_unrecognized     []byte   `json:"-"`
    XXX_sizecache        int32    `json:"-"`
}




func (m *Person) Reset()         { *m = Person{} }
func (m *Person) String() string { return proto.CompactTextString(m) }
func (*Person) ProtoMessage()    {}
func (*Person) Descriptor() ([]byte, []int) {
    return fileDescriptor_4c9e10cf24b1156d, []int{0}
}


func (m *Person) XXX_Unmarshal(b []byte) error {
    return xxx_messageInfo_Person.Unmarshal(m, b)
}
func (m *Person) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
    return xxx_messageInfo_Person.Marshal(b, m, deterministic)
}
func (m *Person) XXX_Merge(src proto.Message) {
    xxx_messageInfo_Person.Merge(m, src)
}
func (m *Person) XXX_Size() int {
    return xxx_messageInfo_Person.Size(m)
}
func (m *Person) XXX_DiscardUnknown() {
    xxx_messageInfo_Person.DiscardUnknown(m)
}


var xxx_messageInfo_Person proto.InternalMessageInfo


func (m *Person) GetName() string {
    if m != nil {
        return m.Name
    }
    return ""
}


func init() {
    proto.RegisterType((*Person)(nil), "Person")
}


func init() { proto.RegisterFile("person.proto", fileDescriptor_4c9e10cf24b1156d) }


var fileDescriptor_4c9e10cf24b1156d = []byte{
    // 67 bytes of a gzipped FileDescriptorProto
    0x1f, 0x8b, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 0xff, 0xe2, 0xe2, 0x29, 0x48, 0x2d, 0x2a,
    0xce, 0xcf, 0xd3, 0x2b, 0x28, 0xca, 0x2f, 0xc9, 0x57, 0x92, 0xe1, 0x62, 0x0b, 0x00, 0xf3, 0x85,
    0x84, 0xb8, 0x58, 0xf2, 0x12, 0x73, 0x53, 0x25, 0x18, 0x15, 0x18, 0x35, 0x38, 0x83, 0xc0, 0xec,
    0x24, 0x36, 0xb0, 0x22, 0x63, 0x40, 0x00, 0x00, 0x00, 0xff, 0xff, 0xa4, 0xaf, 0x53, 0x72, 0x34,
    0x00, 0x00, 0x00,
}

Now the biggest question is what is this person.pb.go file which has been auto-generated by protoc using person.proto . The first couple of points to notice

• Person struct like below. See how type information of person.proto file is used to know what type of field Name is a string

type Person struct {
    Name                 string   `protobuf:"bytes,1,opt,name=name,proto3" json:"name,omitempty"`
    XXX_NoUnkeyedLiteral struct{} `json:"-"`
    XXX_unrecognized     []byte   `json:"-"`
    XXX_sizecache        int32    `json:"-"`
}

•   Person struct also implements a couple of methods that make if of interface type proto.Message.

So basically this autogenerated file generates data accessors for Person struct and it provides methods that allow marshaling/unmarshalling of Person struct type to/from actual bytes. Now let’s write a main.go program to actually create concrete objects of Person struct. Here we will see a couple of advantages which Protocol Buffer has to offer. The below program also shows the read and write of Person struct to file.

main.go

package main


import (
    "fmt"
    "io/ioutil"
    "log"
    proto "github.com/golang/protobuf/proto"
)


func main() {
    person := &Person{Name: "XXX"}
    fmt.Printf("Person's name is %s\n", person.GetName())




    //Now lets write this person object to file
    out, err := proto.Marshal(person)
    if err != nil {
        log.Fatalf("Serialization error: %s", err.Error())
    }
    if err := ioutil.WriteFile("person.bin", out, 0644); err != nil {
        log.Fatalf("Write File Error: %s ", err.Error())
    }
    fmt.Println("Write Success")




    //Read from file
    in, err := ioutil.ReadFile("person.bin")
    if err != nil {
        log.Fatalf("Read File Error: %s ", err.Error())
    }
    person2 := &Person{}
    err2 := proto.Unmarshal(in, person2)
    if err2 != nil {
        log.Fatalf("DeSerialization error: %s", err.Error())
    }


    fmt.Println("Read Success")
    fmt.Printf("Person2's name is %s\n", person2.GetName())
}

To run this file first install protobuf/proto using “go get github.com/golang/protobuf/proto” and then run this file using the command “go run *.go”Output:

Person's name is XXX
Write Success
Read Success
Person2's name is XXX

Notice that in the above program we

• We write a concrete person struct to a file “person.bin”. It is a binary file and not human readable.
• Also we read from the file. It is able to successfully read and print “Person2’s name is XXX”

The astonishing thing about the “person.bin” file is that it is of only 5 bytes as compared if you create a JSON file with the same data that will be of size more than 15 bytes.  Also Marshal and UnMarshal from bytes to concrete objects and vice versa are also very fast as compared to unmarshal and marshaling of JSON files. 
Now we have provided the theory. Let’s write once again the advantages of using Protocol Buffers

1. More clear and less ambiguous than corresponding JSON and XML as there is also type information stored with them.
2. The data stored is relatively smaller in size of almost 2- 3 times smaller.
3. It is much faster. For example, serialization and deserialization is faster with protocol Buffers
4. Automated Code Generation – You write a protocol buffer file and you automatically get a corresponding GO file generated
5. A protocol buffer is used in GRPC which is next-generation replacement of REST protocol – Watch space for here, we will add an article on it soon.

Conclusion: Protocol Buffers have much to offer other than what we have discussed in the article. This provides a quick overview of what protocol buffers are and what are their advantages as compared to JSON/XML format.

The post Protocol Buffers and Go: Getting started appeared first on Welcome To Golang By Example.