# gRPC

gRPC is a modern open source high performance Remote Procedure Call (RPC) framework that can run in any environment.


- Core Features
-
- Client libraries in 11 languages
- Generating efficient client libraries
- Simple service definition framework
- Connecting mobile devices, browser clients to backend services
- **Bi-directional streaming with http/2 based transport**

- Integration Support
-
- Load balancing
- Tracing
- Health checking
- Authentication

- Supported Languages
-

|Language|OS|Compilers / SDK|
|-|-|-
|C/C++| Linux, Mac| GCC 6.3+, Clang 6+
|C/C++| Windows 10+| Visual Studio 2017+
|C# |Linux, Mac |.NET Core, Mono 4+
|C# |Windows 10+| .NET Core, NET 4.5+
|Dart |Windows, Linux, Mac| Dart 2.12+
|Go |Windows, Linux, Mac| Go 1.13+
|Java |Windows, Linux, Mac| Java 8+ (KitKat+ for Android)
|Kotlin| Windows, Linux, Mac| Kotlin 1.3+
|Node.js| Windows, Linux, Mac| Node v8+
|Objective-C| macOS 10.10+, iOS 9.0+| Xcode 12+
|PHP |Linux, Mac |PHP 7.0+
|Python| Windows, Linux, Mac| Python 3.5+
|Ruby |Windows, Linux, Mac |Ruby 2.3+

- Basic Questions
-
- What is the difference between REST APIs and gRPC?
- REST APIs generally use JSON or XML message formats, while gRPC uses protocol buffers. To signal errors, REST APIs use HTTP status codes, while gRPC uses error codes. gRPC’s message sizes tend to be dramatically smaller than those of REST APIs.

- How do protocol buffers work?
- Protocol buffers are gRPC’s format for contract messages. The gRPC library uses this format as its serialization structure, which is in hex binary format.
- Is gRPC faster than REST?
- Yes gRPC is faster than REST
- Is gRPC faster than WebSockets and what should I use
- Performance of gRPC is quite near to that of Java Socket.
- 
- gRPC is using HTTP 2 which is having in-built TLS vs on WS we have to do additional work for WSS
- gRPC is preferred over WebSockets if the application demands various requests processing at one time. gRPC supports multiplexing that arranges different requests seamlessly. But, multiplexing isn’t offered by WebSocket. Hence, one connection is useful only for one request.

- GraphQL vs REST vs gRPC
-

| Feature | GraphQL | REST | gRPC |
|------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------|
| Data fetch | Efficient fetching of data. Only required data will be fetched from server. | Extra data might be returned by the server unless new endpoints/query filters are defined on server side. | Extra data might be returned by server unless new endpoints/filters are defined on server side. |
| HTTP 1.1 vs HTTP 2 | Follows request-response model. It can work with either HTTP version but is typically built with HTTP 1.1. | Follows request-response model. It can work with either HTTP version but is still typically built with HTTP 1.1. | Follows client-response model and is based on HTTP 2. Some servers have workarounds to make it work with HTTP 1.1 but it is not the default. |
| Browser support | Works everywhere. | Works everywhere. | Limited support. Need to use gRPC-Web, which is an extension of gRPC for the web and is based on HTTP 1.1. |
| Payload data structure | Uses JSON-based payloads to send/receive data. | Mostly uses JSON- and XML-based payloads to send/receive data. | Uses Protocol Buffers by default to serialize payload data. |
| Code generation | Need to use third-party tools like GraphQL Code Generator to generate client code. Docs and an interactive playground can be natively generated by using GraphiQL. | Need to use third-party tools like Swagger to generate client code. | gRPC has native support for code generation for various target languages. |
| Request caching | Hard to cache requests by default as every request is sent to the same endpoint. | Easy to cache requests on the client and server sides. Most clients/servers natively support it. | Doesn’t support request/response caching by default. |

- Enough Pros, Cons time
-
- It doesn’t support languages like R and Swift. JSON, which REST uses, is supported by virtually all languages.
- As gRPC heavily uses HTTP/2, it is impossible to call a gRPC service from a web browser directly. No modern browser provides the control needed over web requests to support a gRPC client. Therefore, a proxy layer and gRPC-web are required to perform conversions between HTTP/1.1 and HTTP/2.
- Non-human Readable Format for debugging, developers need additional tools like the gRPC command-line tool to analyze Protobuf payloads
- No requests caching like REST API caching
- HTTP/2 still has some latency issues due to headers being used in each exchange.

- Hedera Consensus Service gRPC API
-
The Hedera Consensus Service (HCS) gRPC API is a public mirror node managed by Hedera for the testnet. It offers the ability to subscribe to HCS topics and receive messages for the topic subscribed.

- Protobufs: https://github.com/hashgraph/hedera-protobufs
- Can use Postman or ClientSDK for easy access

    const { Client, TopicMessageQuery } = require("@hashgraph/sdk");
    const client = Client.forMainnet()
    client.setMirrorNetwork("mainnet-public.mirrornode.hedera.com:443")

    const topicId = `0.0.1343332`;  // Arkhia Topic as example

    new TopicMessageQuery()
        .setTopicId(topicId)
        .setStartTime(1665570300)
        .subscribe(
            client,
            (message) => {
                console.log(Buffer.from(message.contents, "utf8").toString())
            }
        );