Do have particular complaints about Postgraphile that Nest has a better solution for (when constrained to GraphQL, which the author states is a goal)?
The issue here has nothing to do with how PostGraphile is implemented though, I've heard many people complimenting it for being better than alternatives. However the very idea of generating API from DB is problematic because that forces API consumers to think in term of DB operations not business processes. Most likely business logic will be leaked down to clients, or have to be managed in some convoluted way (Hasura actions).
> 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.