Create graphql setup

[BracketJohn]

Goal

Setup prisma ORM + a graphql API provider.

Context

Out of #3 and #2 we want to setup prisma and a graphql api provider (such as apollo, as used here: https://github.com/makerdao-ses/ecosystem-api/blob/main/src/index.ts) to get the project started.

Tasks

• [x] research which gql provider to use
  • [x] prisma has their own examples that we can probably just take over
  • [x] (https://github.com/prisma/prisma-examples)
  • [x] https://github.com/prisma/prisma-examples/tree/latest/typescript
• [x] setup prisma and the graphql provider
• [x] add a hello world model to prisma database
• [x] ensure that the following works:
  • [x] prisma schema generation
  • [ ] graphql schema / types generation
  • [x] a graphql playground

[valiafetisov]

TypeGraphQL also supports prisma), so would be great to see it in the research comparison

[KirillDogadin-std]

1. Nexus
   • uses:
     • Apollo Server
     • GraphQL Nexus
   • downsides:
     • no previous xp of the team
   • upsides:
     • some similarity with how zod defines schemas link
     • derives graphql return structure from prisma types.
2. NestJs
   • uses:
     • NestJs
   • downsides:
     • nit: looks like too much space is taken up by boilerplate e.g.
     • nit: decorators is an experimental feature as here
     • no previous xp of the team
     • within this example: the setup does not derive graphql return structure from prisma code
   • upsides:
     • can infer routes from file location and name
     • single dependency
3. Hapi
   • modification of (1) with hapi
4. fastify
   • schema: as in (1), hence pros and cons are derived from there
5. type graphql
   • as of documentation is compatible with nest-js
   • upsides:
     • automatically generated graphql types
   • downsides:
     • docs only feature nestjs api in combination with the package.

Conclusion:

• I would say that avoiding duplication of the information (db model, graphql model) is desirable. Therefore (2) is out
• (4), (3), (1) are similar and are different from each other essentially by api framework choice
• (5) unlike the options from the point above uses nest.js . It introduces the possibility to use more declarative style of endpoint & schema definitions. E.g. this style vs the other one

Since there's a discussion to take a place about switching to TypeORM, i will leave the current state of investigation.

If we remain with Prisma, the next step would be to play around with the api setups:

How does ... work?:

• middleware injection
• complex queries
• validation
• playground for the api (e.g. swagger)