wasp-lang/wasp

Have Wasp have top level "data schema"

Open

#642 opened on Jun 23, 2022

View on GitHub
 (1 comment) (0 reactions) (0 assignees)Haskell (4,229 stars) (227 forks)batch import
enhancementhelp wantedhmmideamajor featureresearchwow

Description

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:

Contributor guide

Tech stack
prismagraphql
Domain
backenddatabaseapi
Issue type
feature
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
4
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
over 1 week
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
stale
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
needs investigation
Prerequisites
Understanding of Wasp's Entity systemFamiliarity with Prisma schema languageBasic knowledge of GraphQL
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
20
Research direction
The issue proposes designing a top level data schema for Wasp. Three approaches are outlined: custom DSL, GraphQL, or extending Prisma. Research should evaluate each option's feasibility, impact on existing Operations and Prisma integration, and alignment with Wasp's goals. Linked issues #641, #101, #143 provide context. Prototyping the Prisma extension approach (option 3) might be the least disruptive first step.