[Stellar Playground: A browser environment for testing Stellar Network client code] (Version: [14.1.0])

[rokopt]

Description

The concept of the "Stellar Playground", a testing and learning tool for people developing or considering developing on the Stellar Network, has evolved from ideas of @bartekn through a series of conversations (see below).

Prior related issues / PRs

• Dry run mode for transaction submission · Issue #1391 · stellar/stellar-core

• Green: A Language for Building Stellar Ledger Scenarios (Draft SEP)

• change "manual close" to use VIRTUAL_TIME · Issue #1760 · stellar/stellar-core

• Run in-memory / start-from

• Captive Stellar-Core wrapper server (PR: Add HTTP server for managing a remote captive core instance)

• Example of the kind of question to which we’d like to be able to demonstrate an answer: https://stellar.stackexchange.com/questions/4093/which-horizon-post-transaction-responses-are-final-and-immutable

• Captive Stellar-Core: Stream meta data starting from any ledger

• Switch to stellar-core run-from command when added to Stellar-Core

• Remove ambiguous result from "tx" endpoint · Issue #1999 · stellar/stellar-core

External references / models

The following are examples of the kinds of things we might want to build over time:

• Albedo playground: At a glance, it looks to me as though its “Playground” is far more constrained than what we're envisioning here; it's more like the Stellar Laboratory, allowing you to enter constrained sets of parameters to generate various operations. It doesn't give you an interpreter.

• Go playground & tutorials

• Katacoda

• repl.it

• Kubernetes tutorial/playground

• Play with Docker:

• Playground - An online editor for exploring TypeScript and JavaScript

Current vision

As suggested by @MonsieurNicolas , I imagine that the Stellar Playground will be a Stellar-hosted web page (perhaps referenced from somewhere in the new docs and/or API reference and/or Laboratory) resembling the Go Playground. Each user who loads the web page will, as with the Go Playground, have access to an IDE (likely we would reuse one such as Monaco Editor or Theia, the latter of which is used by Gitpod) with a private, sandboxed run time, such as stack and heap, and the ability to call some subset of the language’s SDKs. Since Go is one of the languages for which Stellar provides SDKs, it might specifically be the language, or at least the first language, in which a Playground user can code. We could over time add support for other languages for which we provide SDKs, in the style of multi-language “playgrounds” such as repl.it. One such language could even be a Stellar-specific DSL such as Bartek’s Green. (stellar-core will be agnostic to the languages provided to users; it will be the choice and responsibility of Horizon and the front-end interpreter and IDE to implement support for each language on top of new stellar-core functionality.)

In addition to some subset of standard language SDKs, a Playground instance would also be able to call some APIs from a new Playground SDK, made available for each supported language. Examples of APIs which would only make sense in a Playground might include “perform the following transactions without checking signatures, to establish a starting state for my test” and “close a ledger with the following parameters”.

Part of the private state of a Playground instance would be a virtual Stellar blockchain. In the long run, the user could be given the option of deriving the virtual blockchain’s state from that of a real Stellar network (pubnet, testnet, or some private net to which that Playground instance was given access), or of starting from the state of the genesis ledger (this option could be presented either as a choice made when launching a Playground instance, or as a Playground API call such as “reset playground state to genesis” or “reset playground state to current network state”). Even if a user chooses to use a state derived from the network state (which would be tracked by a stellar-core instance serving that Playground instance while running on the chosen network), assuming we provide that option at all, transactions (and other modifications) “submitted” by the Playground user are not sent to that network, and do not modify any state outside of that one Playground’s runtime.

A Stellar Playground would thereby provide current and potential developers and other ecosystem members, even students and curious enthusiasts, a near-instant, on-demand, browser-based, zero-install opportunity to test or learn to write code that uses the Stellar network through real Stellar APIs. Our own documentation could also embed Playground widgets to provide executable, modifiable illustrations, in the style of the Go tutorial.

[rokopt]

The initial stellar-core component of this has been implemented in PR #2696. If and when we get other components trying to use it, we might create issues for further enhancements, with possibilities including a command for executing transactions with signature-checking disabled and a command for issuing upgrades along with a manualclose.

[rokopt]

I filed stellar/go#3274 to track the next potential step of Horizon starting to use the enhanced "manualclose" to provide some Playground-specific APIs that could be used by a runtime, so we could close this one and consider this one "handed off" to Horizon (if work does continue there and in other components, then it's likely that some more enhancement requests will return to us, but we can file new issues for specific requests as they arise).