[BenjieGillam]

PostGraphile maintainer here; what you’ve said is not really true for PostGraphile - we give you a huge toolbox of ways to customize, shape and extend your schema so it’s designed for consumers to consume rather than just being a way of exposing your database over GraphQL (which I agree is not necessarily the right goal in many cases). It does encourage you to put your business logic in the database, but you can also do logic in JS/TS if you see fit with our powerful plugin system and range of plugin factories for common tasks, such as makeExtendSchemaPlugin for adding your own types and resolvers. It constructs a GraphQL schema using the reference implementation so you can then use the schema with other tools if you like. For an example GraphQL schema that’s client focussed, see: https://graphile-starter.herokuapp.com/graphiql . I care deeply about building high quality GraphQL schemas; this is one of the reasons I contribute to the GraphQL Spec itself.

[nsonha]

I have not used PostGraphile myself so I should not have used such strong words about it. 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). Sure it can be done but at the end is it really more productive with that many indirections? More importantly is it robust, now that your business logic layer is intertwined with your API layer?

[BenjieGillam]

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.

[nsonha]

Thanks, your answer definite gives me some confident in trying PostGraphile for my next project. I agree that "plugin" can just be how we call a thing, it doesn't necessarily entail a heavy abstraction or some sort of lock-in. I'll look further into your suggestions.