| No worries, I think judging things we're unfamiliar with is very human - it's necessary to protect our own time because we can't afford to research _everything_. We just need to be careful to not share these quick judgements as if they are well researched opinions. > I just feel that writing business logic should not be something you have to do in a plugin of some tools or with knowledge of graphql (resolvers) Business logic doesn't need to be written in the resolvers themselves (this is not generally good practice); instead your resolvers call out to your business logic layer as is the GraphQL way. For PostGraphile, in general the "business logic layer" is in the database itself (e.g. PostgreSQL functions, etc) which can be reused directly by other components of your stack (e.g. a REST API), but it doesn't have to be. Is your issue more with how GraphQL in general works (resolvers calling out to the business logic layer), or do you feel that PostGraphile is adding layers of indirection due to an issue with the term "plugin"? If we called them "modules" would you be happier? Here's an example "plugin" that adds a new field to our GraphQL API, where the business logic is contained in a fictitious npm library and we just defer to that in the resolver - this is a common way of writing GraphQL schemas: defining the types/fields via SDL and the accompanying resolver functions: https://gist.github.com/benjie/68f55fa1bcc07e1cd7a8f49d423f1... . In PostGraphile we handle this through plugins because it allows you to mix and match (should you wish) different ways of building your schema (code-first, SDL-first, etc), and it allows you to do full-schema transformations if you wish. An example of full schema transformation is the PgOmitArchived plugin https://github.com/graphile-contrib/pg-omit-archived which adds "soft delete" support to everything in your API with a minimum of fuss - by default soft deleted things are hidden, but you may specify for soft-deleted items to be included, or shown exclusively, using a GraphQL field argument. > is it really more productive I suggest you ask our users why they love us; I suspect you'll find the massive increase in productivity is one of the main reasons. > is it robust, now that your business logic layer is intertwined with your API layer As mentioned above, this needn't be the case; yes, it's robust. |