Xpring SDK: A 10,000 Foot View

Hello, XRP

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.

First, a bit of background. The XRP Ledger is a sophisticated, yet complex, piece of software that runs in the context of a distributed system. Ripple has historically provided a set of SDKs in JavaScript that are fairly close to the metal of this system. There are also a number of older and occasionally deprecated libraries that provide similar functionality in other languages. This state of the world is great for developers who are experts in distributed systems or who want to use advanced features of the XRP Ledger. However, this is not so great for the developer who is just trying to receive an in-app payment for 45¢ so their app can cover its AWS bill this month. Xpring SDK is built to solve this problem.

At Xpring, we want to make it easy for all developers to transact value around the world, regardless of payment size, borders or platform they are programming on. We believe that most enterprise shops that deal with financial products probably don't deal exclusively in JavaScript and that these developers should be able to build in their native language. We believe that the most common use cases for XRP should be easy and accessible to all, regardless of their knowledge of cryptography or distributed systems. Xpring SDK condenses the most common tasks in XRP into minimal lines of code, which “just work.” In fact, in most instances, users see up to 80% savings in lines of code.

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:

• Java
• Swift
• NodeJS (with browser based support arriving imminently)

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.

Architecture

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.

Networking

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.

Fortunately, the XRP ecosystem has historically maintained a robust ecosystem of JavaScript projects that provide most of the functionality we need. The libraries are used by many enterprise sized entities and have been battle tested and withstood the challenge of operation in production. Even better, JavaScript is a prolific language that is able to run on nearly every modern computing platform.

JavaScript's drawbacks are that it is weakly typed and in most environments it runs as an emulated language, making it less performant than native code. Ripple’s libraries use TypeScript, which helps to eliminate some of the type safety concerns. We also believe that by having a small common core, both performance and type safety concerns are mitigated as the surface area is both small and easily auditable by a human.

Xpring SDK consumes a common JavaScript core by binding it to the host language and calling into it for core functionality. This common core is not exposed to users of the public API which minimizes the chances of incorrect use of JavaScript’s type system. Similarly, a small number of call sites minimizes the performance impact of the JavaScript virtual machine. We believe that a common core in JavaScript allows us to have the optimal trade off between the benefits of code reuse, performance and a high level of type safety.

You can check out the core library in Xpring SDK here.

The "Glue"

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.

Since the public API is written natively, it provides an idiomatic design in whatever language the SDK is being written in. For instance, JavaScript engineers generally expect asynchronous code to use promises, while a Swift developer would be more likely to expect a closure completion handler. Our code sharing patterns allow both of these programmers to write code in the way they’d expect, while actually sharing the majority of functionality with each other.

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.

Another great effect of modularity is that it’s easy to swap out components. In the future, if we find emulated JavaScript to be a performance bottleneck, we could rewrite the core code in a more performant language like C++. Additionally, if a new networking technology emerges that provides tangible benefits over gRPC, we can adopt it. Since both components are wrapped in the “glue layer” and hidden behind an idiomatic public API, either of these changes could be performed with zero disruption to end users.

Towards the Future

With the architecture described, the cost for Xpring or any external developer to add an additional platform to our SDK is now very low. One simply needs to invoke a program to generate the necessary gRPC networking code, create a lightweight set of bindings between JavaScript and their language of choice and write the idiomatic public API which glues the two together and is presented to clients.

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.