Early feedback

[VojtechVitek]

Please help us shape gospeak@v1 by providing an early feedback.

[ftjfo]

I just want to add some encouraging words to your project.
As someone who is using WebRPC and is happy with it! I would rank this "code-first" approach as an even better, at least for my use cases with Go<->Typescript RPC. I am surprised that this way of creating interfaces doesn't have more traction in general.

[gsouf]

Hey, just found out about it. Had hard time deciding between webrpc and connect-rpc. I was into webrpc more for the ease of creating new clients, but what bothers me most was the need to use a DSL (ridl) to write my routes.

This one might be the way to go actually ("go" pun unintended)

[VojtechVitek]

What's currently missing in gospeak vs. webrpc:

Design:

• Error definition
• ENUM definition v2 -- a prototype is at https://github.com/golang-cz/gospeak/tree/enum_v2
• Webrpc streaming

We need to come up with the right design first.

Gospeak is already usable right now -- but it's not there 100%. There are missing features & rough edges with go generate. We need to provide more examples and better best practices, e.g. should interface definition be side-by-side to the generated files or in a separate folder?

I don't have much time to improve any of this right now. But I will revisit during the XMas break.

I'm all ears for design ideas!

[gsouf]

@VojtechVitek I strongly believe in this project and I'd be happy to contribute to make it better.

Regarding error management specifically. My need today for a better typed client is to be able to identity which error can the endpoint return. For example in extremely simplified pseudo code:

response = client.getPets();

// Use an **Exhaustive** switch statement
switch response {
  authError:
    // do something
  validationError:
    // do something
  customPerError:
    // do something
  otherCustomPetError:
     // do something
  noError:
      // do something
}

Because the switch here is exhaustive, whenever a new error is added, this switch statement will no longer be valid and we will have to review it.

Also it's worth it to add that some errors might come from generic middlewares, other errors will be specific to one or more endpoints, related to business logic.

I'm wondering whether it would be beneficial to make it possible to distinct them somehow for the client side.

I'm very new to the RPC/webRPC standard so I might also have overseen something here.. My goal being to make it really easy for the client to detect any change from the client via strong typing.

[VojtechVitek]

The errors are currently global in webrpc: https://github.com/webrpc/webrpc/blob/master/_examples/hello-webrpc-ts/webapp/src/client.gen.ts#L256

So, you'd have to handle all possible error types with the exhaustive switch statement.

However, we discussed something similar recently -- and there's a "throw" proposal at webrpc/webrpc#383 to make the errors more fine-grained for each endpoint. It's a very very early concept, though.

[gsouf]

@VojtechVitek is it possible to add more than one service in the same generated client / server file?

[VojtechVitek]

Good question. I've tested this not a long time ago and there were some bugs when using multiple interfaces.

So I the answer is no as of today. But I'd love to revisit this. The end goal is to be able to define multiple services as separate interfaces within one file:

type PublicAPI interface {
     GetUser(context.Context)
}

type AdminAPI interface {
     CreateUser(context.Context)
}