rfcs/2022-11-2-14714-expand-vrl-web-ui-beyond-MVP-status.md
The current MVP for the VRL web playground utilizes WASM and runs the majority of the VRL stdlib, except for six functions. Users can run VRL programs, share their programs online, and try sample event inputs. However, we would like to expand the MVP features which would require more planning and decision making. An outline of what we would like to implement can be found in the Context section below.
Epic covering the progress of the playground:
List of relevant stretch goals:
/lib/vrl/web-playground/public for running VRL under different versions of Vector.The alternatives are covered in a section below but the main concerns have to do with.
Maintainability. We must ensure other engineers can build on top of the playground in the long term.
Timeline. There's six weeks left in Jonathan's internship
Lack of customizability, current alternatives will provide bottlenecks in the long term future for adding more features
The new UI will set up the building blocks for a robust playground experience. Live deploy, auto completion, in line docs, and more desired features will be possible to implement after the building blocks of the site are made. We should be able to have components for tabs, editors, toolbars, and more. Each with the possibility to expand with features that will accomplish the stretch goals.
Why is this change worth it? This change will allow us to expand the current playground to a more long-term maintainable project.
What is the impact of not doing this? The impact will be a less organized code-base (if using graphiql) or a more complex project for what we need the playground to accomplish (going the rust web-framework route).
How does this position us for success in the future? This will allow us to develop a nice onboarding experience for users who want to see what VRL has to offer, making it an easier sell for users, or at the very least an easier demo to potential customers.
Why should we not do this? We should not do this if the MVP playground is already enough and no longer needs more iteration, if we do not forsee making the playground more complex than it already is in the MVP, then the effort will not be useful.
What kind on ongoing burden does this place on the team? The burden will take place in requiring more front end developers or building up context for current Vector developers.
List prior art, the good and bad.
MVP Playground - great demonstration of what can be done, but limited in features we would like
Graphiql-Vector Playground - has more features we want but the codebase is too tightly coupled with graphql
Why can't we simply use or copy them?
The above prior art is not sufficient for what we would like to develop in the future, and can be too difficult to maintain long term.
There were other approaches to expanding the MVP but were not considered due to concerns about maintainability, scope,
This would buy us a lot of front end components, but after diving deep into the repository, some dependencies must be re-written, and stripped from the context of graphql. This means that the project will likely cause tech debt in the long term future. Requiring engineers to ramp up to a mono-repo, familiarize with a lot of css, familiarize with the build tools used, etc.
Jean estimates a week or two of effort to strip down the graphiql mono repo to solely use code-mirror instead of code-mirror-graphql the difference between these two dependencies the latter has tight coupling of syntax highlighting and autocompletion logic for graphql schemas.
We already have an implementation of running VRL within the graphiql context but as mentioned earlier in the RFC, would likely introduce unnecessary tech-debt in the long term, Steve mentioned the graphiql-react library seems to be an implementation of another UI library, which we should at least experiment with first before solely utilizing graphiql.
This introduces a lot of overhead and seems like would require too much effort ramping up to frameworks as Jean mentioned this is not a task to take lightly and has previous experience developing in a rust web framework.
Incremental steps to execute this change. These will be converted to issues after the RFC is approved: