This workspace holds the collection of components for the Read RPC.
- main - Latest released version, stable and production-ready
- develop - Development branch containing the latest changes and features under development
This project relies heavily on NEAR ecosystem crates and uses dependencies directly from Git repositories rather than published crates from crates.io. This approach is necessary because:
- Unpublished Crates: NEAR doesn't publish all the necessary crates required for Read RPC functionality to public registries
- Version Compatibility: We need specific versions or features that may not be available in published releases
- Custom Modifications: Some dependencies require modifications to work optimally with Read RPC
near-jsonrpc-client- Provides JSON RPC client functionality for communicating with NEAR nodesnear-lake-framework- Essential for indexing blockchain data from NEAR Lake (AWS S3 data buckets)
These dependencies are maintained as forks to:
- Ensure compatibility with Read RPC's specific requirements
- Include necessary modifications and patches
- Control the update cycle and maintain stability
- Add features or fixes that haven't been merged upstream yet
When updating NEAR dependencies:
- Check for upstream changes in the original repositories
- Test compatibility with existing Read RPC functionality
- Update fork references in
Cargo.tomlfiles - Ensure all components still build and function correctly
The JSON RPC server implementation that repeats all the APIs current real NEAR JSON RPC but using a different data sources:
- The Read RPC Storage (PostgresDB currently)
- NEAR Lake Data buckets (AWS S3 currently)
- real NEAR JSON RPC
The indexer built on top of Lake Framework that watches the network and stores the StateChanges into the Storage using the designed data schemas.
The indexer built on NEAR Indexer Framework
The indexer built on top of Lake Framework that watches the network and stores the Transactions along with all the related entities (Receipts, ExecutionOutcomes) into the Storage using the specifically defined TransactionDetails structure in a dumped way (using the simplest key-value schema)
The configuration module is responsible for managing the configuration settings of the NEAR ReadRPC project.
The database module provides database abstractions and implementations for storing and retrieving data.
The cache storage module provides caching functionality for improved performance.
The transaction details storage module handles storage of detailed transaction information.
The logic state indexer module provides state indexing functionality.
The readnode primitives module contains common data structures and utilities.
The performance testing module provides tools for testing and benchmarking.
- CHANGELOG.md - Project changelog and version history
- Examples - Usage examples and sample configurations
- RPC Methods - Available RPC methods and their specifications
- Custom RPC Methods - Custom RPC methods specific to Read RPC
- Database Migrations - Database migration procedures and guidelines
- Tracing - Distributed tracing setup and configuration
- PostgreSQL Setup - PostgreSQL-specific configuration and setup
- Database Migrations - Database migration procedures and guidelines
Note! The docker compose is not fully ready yet. It's still in progress. However, you can run the entire project to play around with it. It is still not convenient for development or debugging purposes. We are working on improving it.
Put TOML file config.toml with configuration in the home root of the project.
See the example here.
Run the docker compose:
$ docker-compose up
This will spin up:
read-rpc-server- the JSON RPC serverstate-indexer- the indexer that watches the network and stores theStateChangesinto the Storage using the designed data schemas.tx-indexer- the indexer that watches the network and stores theTransactionsalong with all the related entities (Receipts,ExecutionOutcomes) into the Storage using the specifically definedTransactionDetailsstructure in a dumped way (using the simplest key-value schema)jaeger- the Jaeger instance for tracing (http://localhost:16686)
See examples here.
- Setup all the services to use volumes for the codebase and using
cargo watchto recompile the code on the fly - Come up with the way of changin the configuration for the indexers in a convenient way
- Robust documentation for the docker compose setup
cargo check
cargo fmt --all
cargo run --package <package_name>
Example:
cargo run --profile dev-release --package rpc-server
Please don't forget to handle .env files properly if you're running the package from the root using the proposed approach.
You can move to the folder with a package
cd rpc-server/
And run a package as usually from the folder
cargo run --profile dev-release
In this case you would want to have an .env file in the package folder.
See the tracing documentation here