All Collections
Develop
Why do you recommend using SDK's?
Why do you recommend using SDK's?

The primary benefit of interacting with PassKit over gRPC is speed and efficiency.

Paul Tomes avatar
Written by Paul Tomes
Updated over a week ago

If you are developing your own integration - between your application/service and PassKit - we strongly recommend using our SDKs.

Our SDKs take away all the complexity so you can focus entirely on implementing your business logic. Connections, gRPC marshalling, code auto-completion and documentation are all built into our SDKs. All that you need to do is import our libraries as you would any other for your chosen language.

gRPC’s architectural style is an excellent choice for working across multi-language applications and microservices. Its ability to stream content bi-directionally makes it an efficient choice for systems that require heavier communication loads than single request/response cycles. Its binary data format is far more efficient than RESTful text transfers, and the use of HTTP 2.0 decreases its need to reestablish connections to servers.

Analogy for the non-developer

Let's say you want to ask a friend several questions over the telephone; HTTP 1.1 (RESTful transfers) means we call our friend, ask a question, get an answer, and end the call. We call them again, ask the next question, and end the call again, and so on until we have all of the information we wanted.

When using gRPC, HTTP 2.0 allows us to call our friend one time, give our list of questions, get our list of answers, and then terminate the call, resulting in less overall traffic to reestablish the connection between each question.

More details

This excellent blog post, published by POSTMAN, explains in more detail why gRPC is better. We recommend taking 8 minutes to read the whole article.

For convenience we provide a comparison summary below:

HTTP APIs

gRPC APIs

HTTP version

HTTP 1.1

HTTP 2.0

Communication model

Single request/response communication.

Single request/response communication, and streamed communication.

Browser support

Supported natively.

Requires additional library code and proxies.

Data transfer

Typically JSON or XML but allows customized choices.

Typically uses protocol buffers but allows other types.

Data transfer size

Medium/large.

Small due to generally-used binary format.

Data typing in payload

JSON is not strongly types. XML can include "type" data, but increases its size.

Protocol buffers allow strongly-typed data transfer.

Processing complexity

Higher for text-parsing.

Lower for well-defined binary structure.

Did this answer your question?