Hacker News Reader

Comment by nailer | Hacker News Reader

As a JS/TypeScript dev: just give me typing, DB schema, and an API in one place.

Currently we have TypeORM, which does typing and DB schema but requires you to make a separate API. And we have Prisma, which is a DB schema and API, but still requires you to maintain types.

View on HN

I always hesitate to model an externally facing API to match the underlying database schema because you end up coupling consumers of the API to its internal implementation. Mind you, I'm coming from an enterprise background where systems live way longer than you expect them so, so you need that flexibility.

If that's not a concern, and you want speed/ease of development, take a look at TypeGraphQL [1]. They have a couple of examples [2][3] of how nicely it plays with TypeORM. You can create one set of domain object classes, annotate them with decorators for both TypeGraphQL and TypeORM, and then expose a GraphQL schema that matches the underlying database with a minimal amount of code (you could probably even get clever with some generic fucntions to cut down the code you'd need to write for the resolvers).

[1] https://typegraphql.com/ [2] https://github.com/MichalLytek/type-graphql/tree/v0.17.5/exa... [3] https://github.com/MichalLytek/type-graphql/tree/v0.17.5/exa...

"I always hesitate to model an externally facing API to match the underlying database schema"

True.

Would be nice to have some kind of graphical tool, that would allow to model these things.

Add databases

Extract the schemas from these databases automatically, which should be trivial with SQL databases

Create GraphQL types manually

link the types up with the databases (the tricky part, especially with multiple different databases)

Agreed. Api, business logic, and normalized DB all have different requirements. Smashing them together works great for prototyping but in the long run it leads to pain.

Business logic is seperate from typing, schemas and APIs. APIs and schemas are the same thing - the API is literally a query language for the DB.

  the API is literally a query language for the DB

No, SQL is literally a query language for the DB.

The API is the contract you define for how people with interact with your application. While some people may choose to model this after their underlying database, conceptually, they are very different.

On small applications, maybe you can get away with treating them as one and the same, but for longer-lived applications which need to integrate and co-exist with other systems/services, that choice can come back to bite you.

I'm not saying you shouldn't/can't treat them as the same thing, just be sure you know the trade-offs and long-term repercussions.

The successor of Prisma, Prisma2 [0] does aim to solve the typing issue. It generates a fully typed JS/TS client that you can then use e.g. with autocompletion in VS Code. It is currently in preview, but they aim to release the first "stable" version in Q1 of this year, so pretty soon. You can check the current status at [1]. However, you can try it out right now by installing the preview version via npm.

I am currently playing around with it and although it has some rough edges in corner cases, for 99% of my use cases it was a breeze to work with. Particulary the integration with nexus via the nexus-prisma plugin [2] is plain awesome, i have never had a fully functional graphql endpoint standing in a timeframe of 1 hour.

I am using it in conjunction with NextJS and the resulting developer experience is great, i cant recommend enough to try it out

(I am not affiliated with prisma labs, just a happy user)

[0] https://github.com/prisma/prisma2

[1] https://www.notion.so/Is-Prisma-2-Ready-8b3fba3eaf5b4bf3ab71...

[2] https://github.com/graphql-nexus/nexus-prisma

Nikolas from the Prisma team here, thanks a lot for the shoutout!

For people who want to learn more about using Prisma together with Nexus (which enables exposing DB models via GraphQL), I also recommend checking the next iteration of Nexus that we're currently working on (which will turn into a fully-fledged GraphQL application framework with TypeScript as a first-class citizen): https://nexus-future.now.sh/#/

Let me know if you have any questions!

I’ve found graphql-codegen (https://graphql-code-generator.com/) to be very robust and easy to use. It takes in your schemas and can generate typings for your resolvers, queries, fragments etc. it can even generate helper hooks and HOCs for Apollo client or Relay.

I felt the same way and that’s why I built Warthog - https://warthog.dev. It’s a Node.js code-first GraphQL framework written in TypeScript that utilizes both TypeORM and TypeGraphQL under the hood. You add your resolvers and data models, add Warthog’s decorators and you get an auto-generates GraphQL schema complete with sorting, filtering and pagination. It’s also built to be flexible, as auto-generated GraphQL APIs typically limit your flexibility. Check it out - seems to check your boxes.

Curious, what do you do to maintain types? You can hack together a script or client to pull graphql schema from an endpoint and generate types using Apollos code gen (similar to [0]).

[0] - https://medium.com/open-graphql/automatically-generate-types...

Previously, I made something like TypeORM to re-use TypeScript types on a schema-less database. On my current project I'm using TypeORM itself.

Ideally, GraphQL would sit between your DB/DB schema and APIs.

Also, the Relay compiler will emit Flow types in its compiled fragments by default, and can be configured to emit TypeScript types instead (AFAIK, you can't generate both types simultaneously).

https://relay.dev/docs/en/type-emission

My approach is to use code generation tool to handle the typing and API (server side routing and client side SDK) in one-step.

DB side is not handled by the tool because that's a blackbox the client don't need to know.

Reply on news.ycombinator.com