protobuf-ts VS googleapis

DX for front or back end? The beauty of tRPC is that the types are derived/inferred from the backend runtime code (like, as you type). It would be nigh impossible to do that with grpc(-web) using proto files as the source of truth.

It's possible there's a project out there which could automatically produce proto files from something like zod, json-schema, etc. which could be directly interpreted by TS to provide similar (as you type) DX while still allowing some other language backend to consume the derived proto files (though the DX there would be less than ideal).

If you're just looking for similar TS clients/interfaces for grpc-web then I'd recommend https://github.com/timostamm/protobuf-ts which operates on plain JS objects (no new MyMessage().serialize(), instead the code generator mostly produces TS interfaces for you to work against: const myMessage: MyMessage = pojoConformingToInterface; const binary = MyMessage.toBinary(myMessage);)

https://github.com/timostamm/protobuf-ts (RpcMetaData) https://github.com/timostamm/protobuf-ts/blob/main/MANUAL.md

The second big difference is that we now have auto-generated client and server stubs. For this task, I chose to use buf and the protobuf-ts plugin in order to generate idiomatic Typescript classes and objects. Not only do these classes describe the types we'll use in the server and client, but also includes the actual gRPC implementations used to serialize and send messages back and forth across the wire.

I wouldn’t use grpc with web if you can avoid it. If you’re looking for a ts protobuf library I can recommend this one https://github.com/timostamm/protobuf-ts

https://github.com/timostamm/protobuf-ts looks interesting too.

I'd recommend looking into protobuf-ts (Timo from Buf) or protobuf-es (Buf maintained).

Use a GRPC library for frontend, assuming you want to go with Typescript take a look at https://github.com/timostamm/protobuf-ts Frontend frameworks like Angular/React/Vue don't define what and how to implement backend communication. You can use what you want and how you want it.

And there's also this which is by the same author but came before it: https://github.com/timostamm/protobuf-ts

The latter has code-generation for services and has various transport packages for twirp, grpc, and grpc-web.

This looks very interesting! Anything that can move people away from protobuf.js (which seems to no longer be maintained and depends on prototype values for "default values" meaning that you can't send deserialized protobuf messages to/from web workers) and the "native" JS codegen by Google (which produces code that is both very slow and a awkward to use) is a win in my book.

We're currently using https://github.com/timostamm/protobuf-ts which has been fantastic. It's codegen is dependent on the protoc binary as it is implemented as a protoc plugin, but the code it generates passes the protobuf conformance tests. The generated code also outputs plain objects when deserializing protobuf messages which means it works perfectly when sending stuff to/from web workers. It also has grpc, grpc-web, and twirp clients.

Rich Error Model: This model enables servers to return and clients to consume additional error details expressed as one or more protobuf messages. It further specifies a standard set of error message types to cover the most common error (QuotaFailure, PreconditionFailure, BadRequest, etc). When an error occurs, the server returns the appropriate status code along with an optional error message.

They list search in their public api

https://github.com/googleapis/googleapis/blob/288aa7fb71c9b6...

We structure the repo according to proto packages. It's quite similar to how the googleapis repository is structured.

It's unfortunate that the spec doesn't contain custom fields to a sub-object like other RPC specs, like proto Status [1]. They should have had the message go into a field named "message" and not "detail". And have a field like "details" where the opaque type is serialized, which should be named by the "type" field. The problem is that systems with existing error types may have field name conflicts with type, title, status, detail, or instance, so we'd just dump the actual error into a custom "extension member" which by definition, isn't standard.

[1] https://github.com/googleapis/googleapis/blob/1c8a25ab153eef...

Protobuf (https://github.com/googleapis/googleapis)

All the required changes can be viewed in our last demo, the grpc-rest-app implementation. First, we need to update our proto service interface to help the proxy service make our gRPC service methods available at the right URLs and for the correct HTTP operations. To do this, the Google API HTTP library provides annotations we can add to our proto to describe the correct mappings. The buf tool allows us to include the googleapis dependency as a plugin in our buf.yaml file).

I think this only makes sense if the 3rd party is also throwing custom exceptions.

If you want to reduce coupling you should avoid throwing custom exceptions at all. Semantic information can go in the error message and log. The error type should be used to indicate to your program whether an error is recoverable, retriable or some other action needs to be taken. For example google on has 16 canonical error codes for all APIs.

https://github.com/googleapis/googleapis/blob/master/google/...

OpenAPI and possibly developing reusable, versioned client libraries could help, but it's a major undertaking that gRPC makes redundant. I'd be tempted to use grpc-gateway even if I had to implement a REST API. Try looking into buf and monorepo structures for proto management, e.g. something like GoogleCloudPlatform/microservices-demo. For more thorough proto and grpc-gateway definition examples, see googleapis/googleapis.

Firestone does provide global consistency, so the following quote is incorrect:

> In Cloud Firestore, the data on the client are loaded from the database at different points in time. Even if you listen for realtime updates, results from separate queries will not remain in sync. This creates consistency anomalies and bugs in your app.

Here is a link to the protocol documentation that the clients use to support it: https://github.com/googleapis/googleapis/blob/d0b394f188e8c3...

I'd link to the client implementation but it's quite involved.

Well there is Timestamp defined as a well known type which is available to all implementations despite not being a primitive type [1]. Plus one is obviously able to define any other custom types if necessary- eg as seen in [2].

[1] https://developers.google.com/protocol-buffers/docs/referenc...

[2] https://github.com/googleapis/googleapis/blob/master/google/...