Have Wasp have top level "data schema"

[Martinsos]

Right now we have Entities, which are a way to specify a top level data schema, but we very likely want to push that to another level, in order to unlock deeper understanding of many parts of Wasp.

Ideally we would be able to also define pieces of data that are not necessarily persisted in the database, and then use those on different places, e.g. to describe the return types of Operations, or even their input types, which would then also give us more power to work with Operations in a smarter way. It should also enable better support for TS (which we don't have at all for now btw) since we can be smarter about the types we create in TS. More knowledge is just great in many ways!

There are different ideas on how to achieve this:

1. Replace PSL with our own declarative data schema language and use it to describe database Entities, other pieces of data, ... . So we have this custom sub-dsl for all of it. Lot of work though.
2. Switch to using GraphQL (GQL) to describe the data schema layer in Wasp. That would be a big shift though and it we would need to make that work with Prisma and other parts of Wasp. Should we then switch from HTTP API to GQL API, how would that affect Operations? Not sure. But GQL is a good fit regarding expressivity it has, that is why it is interesting.
3. Build on top of what we have right now with Entities and PSL and add additional constructs to define non-db data and stuff. So kind of like (1) but less extreme because we use what we have from Prisma. Important to notice that Prisma has enum and recently also type which are very interesting for this because they (especially type) bring the whole thing much closer to expressivity of GQL. Maybe we can use type to describe non-db data?

This is still a very vague topic, but it does feel very clear that this is needed for Wasp to be able to advance to the next level of its evolution.

This is connected with:

• Expand our Prisma support (enum, type, other dbs, ...) #641
• Add support for local state? #101
• Generate codebase in TypeScript #143

[Martinsos]

A bit of previous thinking I have done in this general direction.
A bit of context: "Item" is a concept of an "aggregate", which is an entity from the db with some stuff embedded into it -> a logical whole that you deal with around the code. We don't have that in Wasp yet, but have been seriously considering having it at some point. It acts as a central unit for performing CRUD operations.

Item vs Entity vs Data(Schema)

There are multiple ways we are considering in Wasp to describe data/state.

Main ones we have been thinking about are:

1. Item (Aggregate)
2. Entity (Database)
3. Some misc schema, let’s call it just Data

The question is, what is the interplay between these, do we need all of these, can we maybe merge them into one concept, ... .

What is each one of them currently?

1. Item → smth that can be saved/updated/created/read/deleted, smth that we can perform CRUD on.
2. Entity → data persisted in the database.
3. Data → we don’t use this anywhere yet, but it could be a way to describe schema where needed.

Item can be based on Entity (db). But could also be based on smth else! It could be using local storage as its backend, or maybe some external service. Item should have some kind of schema though, to give it powers.

Therefore, every Entity can be used as an Item.

In a sense, Data is the basic concept → schema of some piece of data.
Then, Entity is Data persisted in the database → DatabaseData.
Finally, Item is Data that can be CRUD-ed → CrudData.
So we get to: Data, DatabaseData, CrudData.
CrudData is client-focused, and it is a subset of DatabaseData.

Or maybe we could have: Item → Entity, Entity → DbEntity, Data?

I always wanted to think of all these more like “Here is a piece of data I work with, an entity, and I will figure out what I will do with it”. So I wanted to have Entity as the center of everything, and then figure out if it needs to be stored into the database, fetched from Twitter, stored in local storage, ... . So really an Entity was supposed to be a Business Domain Thing (Model?) → something I think about when writing down high level specification of my app.

It would be cool if people can define their own Items. They can use anything they want to persist them. Kind of like Apollo supports with its resolvers.