4 ms·

More closely related to gRPC, Protobufs over HTTP is great too. You can then take advantage of cache-control, last-modified, etc headers in browsers and on CDNs

More closely related to gRPC, Protobufs over HTTP is great too. You can then take advantage of cache-control, last-modified, etc headers in browsers and on CDNs instead of having to reimplement them. My current favorite way to make APIs is using this, and allowing user to request json as well, using a query parameter or header. This is easy to do with protojson conversion

tiew9Vii 3y ago
Agreed! Had good success doing this with a toy mapping web app. Serializing polylines with Protobufs significantly reduced payload size compared to a JSON `[number,number][]` and as it was HTTP I could offload onto a CDN by setting cache-control headers. Developer experience is also much nicer. Instead of repeatedly writing JSON serializers/deserializers on the backed + fronted you get them generated for free. I know there's various open API/json schemas code generators but for me i'd rather use Protobuf's at that point and get the benefits of a strongly typed schema, schema evolution, reduced payload size so faster experience for the user, cheaper bandwidth and cheaper storage if you currently store opaque JSON blobs in the db. JSON API's are api's in debug mode.
dontlaugh 3y ago
You can get very close with Twirp, without losing endpoint definitions. It’s such a simple protocol you can even manually implement client wrappers or server endpoints without much difficulty.
- chocolatkey 3y ago
  Thanks for the suggestion, I'm considering forking that and adding support for GET requests since caching POSTs is not ideal
rswail 3y ago
In other words, by using a RESTful style, with HTTP as the protocol, you get all the benefits of REST. The fact that you're using protobuf as the media type is irrelevant to the protocol. As for the content negotiation for JSON vs protobuf, that's also defined in the HTTP standard. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ac...

tiew9Vii 3y ago

Agreed! Had good success doing this with a toy mapping web app. Serializing polylines with Protobufs significantly reduced payload size compared to a JSON `[number,number][]` and as it was HTTP I could offload onto a CDN by setting cache-control headers. Developer experience is also much nicer. Instead of repeatedly writing JSON serializers/deserializers on the backed + fronted you get them generated for free. I know there's various open API/json schemas code generators but for me i'd rather use Protobuf's at that point and get the benefits of a strongly typed schema, schema evolution, reduced payload size so faster experience for the user, cheaper bandwidth and cheaper storage if you currently store opaque JSON blobs in the db. JSON API's are api's in debug mode.

dontlaugh 3y ago

You can get very close with Twirp, without losing endpoint definitions. It’s such a simple protocol you can even manually implement client wrappers or server endpoints without much difficulty.

chocolatkey 3y ago
Thanks for the suggestion, I'm considering forking that and adding support for GET requests since caching POSTs is not ideal

rswail 3y ago

In other words, by using a RESTful style, with HTTP as the protocol, you get all the benefits of REST. The fact that you're using protobuf as the media type is irrelevant to the protocol. As for the content negotiation for JSON vs protobuf, that's also defined in the HTTP standard. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ac...