In early October, Xpring launched Xpring SDK, a set of language specific libraries which made it easy to interact with XRP. As the creator of Xpring SDK, I wanted to take an opportunity to provide some insight into what Xpring has released, our future plans, and the technical architecture of our SDKs.
What Comes in the Box
Xpring SDK delivers the most common features of the XRP ecosystem in an easy to use package. Xpring SDK is the foundation for the new Xpring Developer Site and will also power future Xpring services.
The following features are supported:
- Checking an Account Balance
- XRP Payments
- Transaction Status
- Transaction History (Coming Soon!)
These features are supported across the following languages:
Most importantly, all of the features use a common code base which ensures we deliver features across all platforms simultaneously. In practice, this means that an iOS engineer who is integrating the Xpring SDK could explain how to use the APIs to their peer Android engineer, since the function calls and APIs follow the same paradigms modulo syntactical differences in the languages.
Xpring SDK achieves cross platform consistency via pragmatic code reuse. At a high level, you can break a multi-platform SDK into three components:
- Networking and Remote Procedure Calls (RPCs)
- Common Core Functionality
- A public API which wires together the former two in an idiomatic API
Let’s take a quick look at each of these components. A future blog post will dive deeply into the technical architecture of each.
Any client side library needs a reliable way to communicate with a remote service. In the case of Xpring SDK, a client side library connects to a remote XRP Ledger node which serves data about the state of the XRP Ledger across the distributed system.
As of today, the XRP Ledger Node uses a JSON API to communicate and interact with the node. While well documented, the API has no preconfigured bindings in each language, requiring developers of client libraries to interact with the node by hand rolling their own untyped JSON objects in their language of choice.
gRPC is a cross platform technology that allows us to define an API using a lightweight markup language. The markup language is then “compiled” to generate code in a number of native languages. The generated code builds request and response objects for the client which are type safe and human readable. It also provides built in connection management, error handling and uses an on-wire format that outperforms JSON in both serialization time and payload size.
By utilizing gRPC in our technology stack, we only need to write code once in order to generate a networking API layer that behaves consistently in every language we support across our stack. You can check out the pull request to merge gRPC support into rippled here.
Common Core Functionality
Any sufficiently complicated system contains a common core of logic that will always behave the same way. In the XRP ecosystem, examples include:
- Address derivation and validation
- Serializing transactions to a binary format
- Base58 Check Encoding
These sorts of functions are finicky, difficult to get correct, not particularly fun to write or maintain, and generally prone to drive developers nuts.
You can check out the core library in Xpring SDK here.
With a common set of core functions and generated network layer, one can simply start creating higher levels of functionality by binding the two together. The binding code sequences calls to the two subsystems and provides an idiomatic public API.
On the Importance of Modularity
Xpring SDK is built with modularity in mind. This makes it possible for unsupported platforms to have a baseline level of support and creates an opportunity for third party developers to make meaningful contributions to the XRP ecosystem by wrapping up our open source components.
For instance, a developer may be interested in using Python to integrate the XRP Ledger with their exchange. Provided a gRPC representation of the network interface, the developer will be able to immediately gain access to any network calls they'd like to use. Additionally, with minimal effort, the developer should be able to wrap up the core library and leverage Xpring SDK's existing code.
Towards the Future
Similarly, the cost of adding an additional feature across platforms becomes lower as well. Any feature implemented on one platform is easy to implement on all other platforms because of the level of code reuse.
While the effect of adding an additional feature or platform is undoubtedly multiplicative, the architecture of Xpring SDK minimizes the incremental cost per feature or platform and implicitly enforces common functionality and behavior across all surface areas.
In the short term, Xpring SDK will grow to support more features of the XRP Ledger. In the medium term, Xpring intends to increase the number of languages covered by the SDK. Finally, in the long term, Xpring SDK will begin to cover additional services from Ripple, such as the cross currency payments or digital identity system provided by Interledger Protocol and will become a one stop shop for all protocols and tools developed by Xpring.
Interested in getting started working with Xpring SDK or XRP? Head on over to the documentation to get started. Want to see your favorite platform of feature in Xpring SDK? Get in touch.