apex / rpc Goto Github PK

Support for generating the client

Not a huge fan of the StatusProvider type stuff I have at the moment https://github.com/apex/rpc/blob/master/error.go#L7-L15, would be nice to also provide some functions for the common scenarios to keep them uniform. Likely move to a sub pkg.

It would be great to generate Terraform providers, maybe not for all methods, but it could be opt-in per method.

I need to look into inheriting from json-schema more, but I think we would then have to support everything JSON-Schema does — oneOf for example — but it would be nice to support the entire thing.

Support for generating the client

Right now it's something like element 5: message is required, might be nicer to use a json-path-ish thing like events[5].message is required. Some tests would also be nice haha

Just add a comment so you can quickly see which version a client supports

Support for generating the client

Support for generating the client

Currently it's snake_cased: https://github.com/apex/rpc/blob/master/generators/tstypes/testdata/todo_types.ts#L4

I'm using prettier on my codebase which is a very opinionated code formatter and I guess many other people are too considering the number of stars it has on github.

Prettier is strict about using camelCasing for object field names so it gives me very annoying eslint errors when I try to instantiate api types.

It would be great if we had a flag in the generator to generate camelCased fields instead. WDYT?

Currently the generated typescript client code simply uses JSON.parse() when parsing responses. timestamp fields will get decoded as strings while in the generated type they're marked as a Date object.

I guess it's related to #3 since validation and decoding would be done at the same time?

This is just my personal stuff, it's not going to be useful for anyone else.

Right now this prevents it from being useful to anyone else https://github.com/apex/rpc/blob/master/schema/schema.go#L165

Would be nice to auto-generate a little example to show on https://pkg.go.dev/, might not be very useful since it's pretty self-explanatory, but at least show the Client initialization

:D

Not sure if it would differ much from the TypeScript/JS Node one, maybe not if it has fetch()

As the title says, would just be nice for documentation to record the version which introduces a particular type, field, or method, not a huge priority though.

Support for generating the client

This stuff I have now is kind of temporary, still need to decide what I want there, maybe opentracing support.

Prerequisites

• I searched to see if the issue already exists.
  Related to #7 .

Description

The library could be made isomorphic and therefore also run on client-side JavaScript runtimes if we used a library like isomorphic-(un)fetch. Furthermore using a cross-environment fetch implementation would work on both client-side and deno.
Node would still need to import a package AFAIK you could define the function in the global scope outside of this library, before requiring it, but I don't think it would be ideal.

To make the node implementation isomorphic it would take nothing more than changing the node-fetch import to some isomorphic library. I suggest we do this change internally rather than relying on the user aliasing the module with some bundler like webpack, as not everyone uses it.

Keeping all of this in mind, I think we could could kill two birds with one stone here by simply adding a --fetch-library argument to specify the desired input library or removing it (for deno) with some arbitrary value.

Examples:
--fetch-library=isomorphic-unfetch:

import fetch from 'isomorphic-unfetch'

--fetch-library=deno:

/* no import required */

Not a big priority for me, but might be a nice option to generate CLIs, pretty much a 1:1 mapping, for example logs add_project --name 'My Project' --description 'Production logs for My Project' --retention 30 --location us-central1.

Output would be a Go program so it's easy to cross-compile and distribute. Would likely also need some env var support generated for auth etc.

Support for generating the client

Right now there isn't much

Support for generating the client

Discussion arose from #23

Hello!

Very interested in this library! Looks very useful.

I'm interested in how you approach error handling with this library, but could not find any examples or docs.

Examples of errors might be resource not found for a given id, user not authenticated, user not authorized, etc.

Thanks,
Louis

Support for generating the client

We could potentially generate mock servers from any schema, as long as it has example responses defined then just return one of those at random. It could be a nice way for people to test their client implementations.