Integrate web framework with MovR

[ericharmeling]

After some initial confusion about what exactly the MovR application is/does, I think we need to:

1. Improve how we document MovR (see Use MovR for docs examples - Phase 1 docs#2849 (comment), MovR Documentation docs#5061, and Update demo and workload flags for new workload(s) in 19.2 docs#5062).
2. Do more development work on the MovR application itself. If we want to make MovR the go-to example application for CockroachDB, it would help if we extended the application to be a fully-functional, full-stack application (with a web UI and everything). This would help a lot with demos and doc examples (especially for developers looking to use CockroachDB as their backend DB of choice)... And it would make a fun Friday project!

@awoods187 thoughts? If this isn't a direction we want to go in, or if you think we could use our doc resources (i.e. me) in a different area, let me know!

Branch: https://github.com/ericharmeling/movr/tree/web-server

[nstewart]

I did some small amount of work to start converting movr to an API server that would support a web FE -- but that is making very slow Flex Friday progress: https://github.com/nstewart/movr-zeit/tree/now

I think adding the rest of the stack is useful, but I think that's solving a separate problem than the original scope. One project is about creating a default data set to try out sql (and other CockroachDB) functionality, the other is creating an example app to help create new apps faster. For example: https://github.com/anfederico/Flaskex

I'll defer to the SQL team on that scope, just sharing as a consideration.

+1 on enhancing the load generator in general though

[awoods187]

I'm into this idea. What if we have MovR run as a managed product for dogfooding? They recently made a call for this and it would give you ready access for using with docs. I think we could even give read only access out to users as an interactive doc which would be cool.

Regardless I do agree with nate's sentiments about making sure we don't do everything all at once---we can be incremental in our approach here

[ericharmeling]

Thanks for pointing me towards that branch, Nate. Glad to hear that's already an idea in progress. I'll check out what you've done there so far!

To your point about making sure we differentiate these two separate projects, I totally agree. As Andy suggests, we should do one thing at a time, starting with whatever is the main priority, which I suspect is the original scope of MovR ("creating a default data set to try out sql (and other CockroachDB) functionality"). It looks like a lot of work has been done on that already, with the movr dataset now in the whitelisted workloads for 19.2 (see cockroachdb/cockroach#37709 and cockroachdb/cockroach#38203). I've started updating SQL examples (see https://github.com/ericharmeling/docs/tree/movr-update), and I think that's in line with the original scope of this application.

... I think we could even give read only access out to users as an interactive doc which would be cool.

I really love that idea Andy. I'm all in for making contributions to that (even if just as a Friday project)!

[bdarnell]

I also think we should have a more complete example app (or many!), and I'm working on one now (as a part of my exploration of serverless ideas). It's important to show people an end-to-end example of stuff that works well together. I'd go further than Flaskex does and include things like testing and monitoring in this scope.

[awoods187]

@ericharmeling let's talk more about this when I return from vacation. I think this would be a great project to work on.

[ericharmeling]

Closing this (see https://github.com/cockroachlabs/movr-flask).