improve query ergonomics #31
Conversation
refs #21
There was a problem hiding this comment.
This looks great overall.
server.ts has grown quite a bit. At the risk of duplicating graphql docs, could you add some comments narrating what is happening or otherwise outline the structure of the file?
Would it make sense to break server.ts apart a bit? Eg put resolvers into their own directory, like resolvers/organization.ts? I'm torn between being able to see the logic all in one place (so you don't have to open 5,000 files and understand each one to make one change) and having more independent pieces that are individually easier to search for and modify.
colocate model-specific graphql code with the models use sequelize virtual fields for all special model properties (tag totals) put utility functions in a helper module
just did a major refactor - i colocated all of the model-specific graphql code into the models themselves -- this way, graphql definitions related to each model's columns and special aggregate query columns are right next to the definitions or custom queries. i think this makes more sense! |
|
an additional refactor step for the future, maybe? create a directory for each model, and have typedefs, sequelize models, and graphql defs each have a file |
|
see #33 |
fixes #21
fixes #9
use custom resolvers to offer enum argument types
offer "meta" org fields alongside org query, which removes the requirement for the organizationMeta query.
upside: better api
downside: basically writing our own ORM. maybe it's time to look at knex? 😒
todo: