[Azeralthefallen]

Except utilizing loopback i simply define my models, what fields are exposed by models, and their relationships. I can easily implement RBAC restrictions via a simple access hook or ACL's.

To me having to maintain two separate graphql services for a single API seems extremely convoluted. I can't expose the private api to any other internal services, because all the authorization and restrictions are done on the application layer.

To me isn't that just using a GraphQL server as an ORM? To me that seems like an extremely roundabout way to do something like that.

[adamkl]

Well, Postgraphile is offering you a shortcut that comes with limitations.

A more complete approach would be to structure your application in a more typical fashion, and put a GraphQL layer on top. Have a data access layer that maps from our back end sources (databases/REST/RPC services) to GraphQL types. Then have a logic/authorization layer, with GraphQL on top. Using Postgrapile seems to take those application layers away for the sake of convenience.

[tomnipotent]

> because all the authorization and restrictions are done on the application layer.

Which application tier? It sounds like you're using GraphQL in-memory to query the database in the same process that's creating the GraphQL query. You should be treating GraphQL as a database, and it should not exist on the same machine that's using it. This way your GraphQL app has centralized permissions & auth, and all your other apps would then be beholden to whatever you implemented.

> just using a GraphQL server as an ORM

If you're using it the way above, then yes. But that's the wrong way to use it.