ffeac298a2
* fix: ignore unknown fields in more RPC responses * Remove mdbook infrastructure * Delete gitattributes and other theme related items Move all docs to /docs folder to support Docusaurus * all docs need to be moved to /docs * can be changed in the future Add Docusaurus infrastructure * initialize docusaurus repo Remove trailing whitespace, add support for eslint Change Docusaurus configuration to support `src` * No need to rename the folder! Change a setting and we're all good to go. * Fixing rebase items * Remove unneccessary markdown file, fix type * Some fonts are hard to read. Others, not so much. Rubik, you've been sidelined. Roboto, into the limelight! * As much as we all love tutorials, I think we all can navigate around a markdown file. Say goodbye, `mdx.md`. * Setup deployment infrastructure * Move docs job from buildkite to travic * Fix travis config * Add vercel token to travis config * Only deploy docs after merge * Docker rust env * Revert "Docker rust env" This reverts commit f84bc208e807aab1c0d97c7588bbfada1fedfa7c. * Build CLI usage from docker * Pacify shellcheck * Run job on PR and new commits for publication * Update README * Fix svg image building * shellcheck Co-authored-by: Michael Vines <mvines@gmail.com> Co-authored-by: Ryan Shea <rmshea@users.noreply.github.com> Co-authored-by: publish-docs.sh <maintainers@solana.com>
2.6 KiB
title
| title |
|---|
| Rust Clients |
Problem
High-level tests, such as bench-tps, are written in terms of the Client
trait. When we execute these tests as part of the test suite, we use the
low-level BankClient implementation. When we need to run the same test
against a cluster, we use the ThinClient implementation. The problem with
that approach is that it means the trait will continually expand to include new
utility functions and all implementations of it need to add the new
functionality. By separating the user-facing object from the trait that abstracts
the network interface, we can expand the user-facing object to include all sorts
of useful functionality, such as the "spinner" from RpcClient, without concern
for needing to extend the trait and its implementations.
Proposed Solution
Instead of implementing the Client trait, ThinClient should be constructed
with an implementation of it. That way, all utility functions currently in the
Client trait can move into ThinClient. ThinClient could then move into
solana-sdk since all its network dependencies would be in the implementation
of Client. We would then add a new implementation of Client, called
ClusterClient, and that would live in the solana-client crate, where
ThinClient currently resides.
After this reorg, any code needing a client would be written in terms of
ThinClient. In unit tests, the functionality would be invoked with
ThinClient<BankClient>, whereas main() functions, benchmarks and
integration tests would invoke it with ThinClient<ClusterClient>.
If higher-level components require more functionality than what could be
implemented by BankClient, it should be implemented by a second object
that implements a second trait, following the same pattern described here.
Error Handling
The Client should use the existing TransportError enum for errors, except
that the Custom(String) field should be changed to Custom(Box<dyn Error>).
Implementation Strategy
- Add new object to
solana-sdk,RpcClientTng, where theTngsuffix is temporary and stands for "The Next Generation" - Initialize
RpcClientTngwith aSyncClientimplementation. - Add new object to
solana-sdk,ThinClientTng; initialize it withRpcClientTngand anAsyncClientimplementation - Move all unit-tests from
BankClienttoThinClientTng<BankClient> - Add
ClusterClient - Move
ThinClientusers toThinClientTng<ClusterClient> - Delete
ThinClientand renameThinClientTngtoThinClient - Move
RpcClientusers to newThinClient<ClusterClient> - Delete
RpcClientand renameRpcClientTngtoRpcClient