5 ms·

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 imp

by adamkl 7y ago

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/ https://typegraphql.com/ [2] https://github.com/MichalLytek/type-graphql/tree/v0.17.5/examples/typeorm-basic-usage https://github.com/MichalLytek/type-graphql/tree/v0.17.5/exa... [3] https://github.com/MichalLytek/type-graphql/tree/v0.17.5/examples/typeorm-lazy-relations https://github.com/MichalLytek/type-graphql/tree/v0.17.5/exa...

k__ 7y ago
"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)
jayd16 7y ago
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.
- nailer 7y ago
  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.
  - adamkl 7y ago
    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.

by adamkl 7y ago

k__ 7y ago

"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)

jayd16 7y ago

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.

nailer 7y ago
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.
- adamkl 7y ago
  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.