Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Configurable clients #624

Closed
BelfordZ opened this issue Apr 15, 2021 · 5 comments
Closed

Configurable clients #624

BelfordZ opened this issue Apr 15, 2021 · 5 comments
Labels
Projects

Comments

@BelfordZ
Copy link
Member

BelfordZ commented Apr 15, 2021

Generated clients lack the ability to configure the various components of the client (RequestManager, Transport, Client itself).

An example of this issue is that there is no ability to set the http transport headers.

The solution should allow for runtime, as well as generate-time configuration of these items.

at runtime, the options should be allowed via constructor params.

at generate time, the options should be pulled from the generator config for the component.

@BelfordZ
Copy link
Member Author

perhaps the contructor should just accept a transport instance instead of configurations? either/or?

@zcstarr
Copy link
Member

zcstarr commented Apr 16, 2021

Yeah I think you're leaning the right way on that . I think RequestManager should stay encapsulated because we don't want to leak those internals, and we should have a request option.
Maybe something like

createTransport(...)=>Transport 
/* Takes all the transport config data that gets handle in the constructor and instead  is handled by createTransport. This is exported but not the underlying transports, so outside of the generic interface, 
there shouldn't be transport construction going on outside of the method.
So we can keep tweaking the internal representation
*/
const transport = [createTransport({host,port,type,path},options)]
new Client(transports,{nextId: ()=> string | int})

Curious on what you think or is this what you're think as well ?

@BelfordZ
Copy link
Member Author

yep, I think thats the idea. As an addition to that, we would probably be able to add configurability from the generator config file (in here: https://github.com/open-rpc/generator/blob/master/test-generator-config.json#L6). This would allow users to produce a generated result that has some preset headers (so that the end-user doesn't need to muck around with passing in the same options every time)

@stale
Copy link

stale bot commented Jun 16, 2021

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Jun 16, 2021
@stale stale bot closed this as completed Jun 26, 2021
@shanejonas shanejonas reopened this Jul 12, 2021
@stale stale bot removed the stale label Jul 12, 2021
@zcstarr zcstarr added this to Icebox in OpenRPC Aug 13, 2021
@stale
Copy link

stale bot commented Oct 2, 2021

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Oct 2, 2021
@stale stale bot closed this as completed Apr 18, 2022
OpenRPC automation moved this from Icebox to Done Apr 18, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
OpenRPC
  
Done
Development

No branches or pull requests

3 participants