gRPC, SOAP, GraphQL

RPC

Another paradigm for creating web APIs is Remote Procedure Call (RPC).

A procedure call but here we call a method on a remote server.

// a Java method
String getName(long id){
	return "John Doe";
}

// method call
getName(1234);		// "John Doe"

The equivalent as an RPC is:

Request:

GET /getName HTTP/1.1
HOST: api.example.com
Content-Type: application/json

{"id": "1234"}

Response:

HTTP/1.1 200 OK
{ "name": "John Doe" }

In the above example, we’ve sent the data as JSON so it is a JSON-RPC. We can also send the data as XML fields, or standardized enveloped XML message as in SOAP protocol.

Ethereum uses JSON-RPC.

RPC vs REST

While REST is resource-oriented, RPC is action-oriented.

Endpoints in REST are noun based, in RPC they are verb based.

REST expects the server to know “what to do”, we can send POST or DELETE request to the same URI and these HTTP verbs will be used to differentiate what the server does in each case. In RPC, the onus is on the client, it is expected to know what to do and call the appropriate endpoint to achieve that.

RPCs are much faster than REST APIs.

gRPC

gRPC is a modern open-source high performance RPC framework created by Google (circa 2016) that uses HTTP/2. It uses its own custom binary data exchange format called ProtoBuf which packs down smaller than JSON after compression but isn’t human readable when in transit (before unmarshalling).

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

Apache Thrift is an alternative to gRPC and has its own binary message exchange format.

gRPCurl - like cURL, but for gRPC.

SOAP

SOAP is an acronym for Simple Object Access Protocol. It is an XML-based messaging protocol for exchanging information among applications which are built with different programming languages. SOAP works over HTTP.

SOAP messages are heavily standardized and it’s popularity is dwindling as REST is generally faster.

POST /InStock HTTP/1.1
Host: www.example.org
Content-Type: application/soap+xml; charset=utf-8
Content-Length: 299
SOAPAction: "http://www.w3.org/2003/05/soap-envelope"

<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:m="http://www.example.org">
  <soap:Header>
  </soap:Header>
  <soap:Body>
    <m:GetStockPrice>
      <m:StockName>T</m:StockName>
    </m:GetStockPrice>
  </soap:Body>
</soap:Envelope>

SOAP - Wikipedia

GraphQL

GraphQL is an open-source data query and manipulation language for APIs, and a runtime for fulfilling queries with existing data.

It sits between the client and the server and specifies what all fields to return in the response, and we get only those fields back.

There is only a single endpoint and the call is similar to RPC.

Query:

{
  employee {
    name
  }
}

Result:

{
  "employee": {
    "name": "John Doe"
  }
}

It was built by Facebook to solve the problem of under-fetching and over-fetching of data in mobile app and web app.

GraphQL is the right choice when you have diverse clients with different data needs. If your interviewer mentions scenarios like “the mobile app needs different data than the web app” or asks about “avoiding over-fetching and under-fetching,” they’re likely looking for you to bring up GraphQL. It’s also a good choice when frontend teams need to iterate quickly without backend changes. With REST, adding a new field to a mobile screen often requires backend changes and API deployments. With GraphQL, the frontend team can request additional fields as long as they exist in the schema.

.graphql schema file:

type Event {
  id: ID!
  name: String!
  date: DateTime!
  venue: Venue!
  tickets: [Ticket!]!
}

type Venue {
  id: ID!
  name: String!
  address: String!
}

type Query {
  event(id: ID!): Event
  events(limit: Int, after: String): [Event!]!
}

Highly susceptible to N+1 problem, and redundancy in data across responses e.g. when fetching a channel’s posts the author name is repeated for every post entry in JSON.

GraphQL also handles authorization differently. Instead of securing entire endpoints like REST, you secure individual fields. A user might see an event’s name and date but not the venue data. You can control this at the field level in your schema resolvers.

Tutorial: howtographql.com

References