My Professional Profile

I am Johnson Augustine Sr.Software Engineer and System Architect. I have 10 Yrs of hands on expertise in MVC 5 , Angular 5 , C# MVC Razor, WPF MVVM , Android , IOS Swift 3 , IOS11 MSSQL,MySQL Database,,PHP,C/C++/Visual C++/G++/QT++,Com,DirectX,Open CV,EMGU CV , embedded System Development , [Raspberry PI]. ,html,Javascript,Jquery,Ajax.CSS , Networking ,Cyber security, Ethical Hacking You can see my professional profile at Email :

Friday, 17 November 2017


The transport layer works using HTTP/2 on top of TCP/IP. It allows for lower latency (faster) connections that can take advantage of a single connection from client to server (which makes more efficient use of connection and can result in more efficient use of server resources.

HTTP/2 also supports bidirectional connectivity and asynchronous connectivity. So it is possible for the server to efficiently make contact with client to send messages (async response/notifications, etc..)

While, both REST and gRPC can generate client/server stubs (using something like swagger for REST), REST has a limited set of primary 'function' calls (or verbs):

| HTTP Verb |      CRUD      |
| GET       | Read           |
| PUT       | Update/Replace |
| PATCH     | Update/Modify  |
| DELETE    | Delete         |

whereas gRPC you can define any kind of function calls including synchronous/asynchronous, uni-direction/bidirectional(streams), etc..

Using gRPC the client makes a call to a local method. To the programmer, it looks like you're making a local call, but the underlying layer (the auto-generated client stub) sends the call to the server. To the server it looks like it's method was called locally.

gRPC takes care of all the underlying plumbing and simplifies the programming paradigm. However, to some dedicated REST purists, this may seem like an over-complication.

No comments:

Post a Comment

Note: only a member of this blog may post a comment.