Figure out a way to run Paper Playground without PostreSQL

[jessegreenberg]

We want to investigate running this project without a database. Though shared spaces wouldn't work, it would make it really easy for anyone to start creating projects with Creator/Paper Playground.

[jessegreenberg]

Earlier, we discussed possibly using local storage for this or a server-side solution.

After thinking about this a bit more I think using the server is the best way to go.

1. It will be quite a bit easier. If we do this all with local storage (in the front end client) we need to modify all usages of xhr to communicate with local storage instead of the server. If we use the server, we can just update the api file to serve from local files in a "local" mode. This means we only make changes to one file.
2. It is probably better practice. This keeps the server/client (model/view) modularity. It puts less burden on the front end.
3. Pre-populated projects/spaces/programs will be easier to put in. We can track them with git, and just put json files into the directory. A localStorage solution means things only get added/changed during runtime.

I wanted to note that its currently possible to use a local postgreSQL database to run paper playground. But switching to a JSON representation of saved projects/data on the server means that people will be able to run projects locally without setting up a database (very complicated and huge barrier to overcome).

[jessegreenberg]

This is likely the process:

1. Add a mode to the .env file that makes the project run in "local" mode.
2. In that mode, opt out of knex since we are going to use file handling instead.
3. Update routes to use file handling instead of knex. Consider a service layer that performs operations on JSON files mimicking the database oprations.
4. The save operations likely write directly to files instead of updating an in-memory state. This is more simple and paper playground doesn't need immediate persistence of changes.
5. Other than the template files, saves should likely be excluded from git.

Consider a service layer that performs operations on JSON files mimicking the database oprations.

Brainstorming a path:
Create IDataService.js - an interface for querying the data with the api.
Create KnexDataService.js - An implementation of IDataService.js, using knex (as is currently done).
Create LocalFileDataService.js - An implementation of IDataService, using file IO to get the data in the same format.

The IDataService defines the signatures so we can confirm that the output is the same (I wish we had TypeScript for this).

[jessegreenberg]

A branch was started for this called local-file-serving.

[jessegreenberg]

local-file-serving was merged into main. So far it is working quite well! We will create new issues as problems come up, the bulk of the work is done. Closing.