I have been deep-diving into graphql lately, as it seems like it very completely fixes the client-side N+1 query problem (you can specify everything, including

I have been deep-diving into graphql lately, as it seems like it very completely fixes the client-side N+1 query problem (you can specify everything, including children of children in hierarchical data, that you'll need to render a page in a single fetch request), and the return-to-rpc feel of mutations is also kind of nice after feeling a bit over-constrained by REST conventions for some edge-case mutation actions. That said, when I looked last postgraphile didn't handle has many and belongs to many relationships out of the box. I do this a lot, with a mostly-standard pattern of naming and so on, with a join table in postgres. This lets me do stuff like "sort this list by the timestamp of when the member of the community was added" (which is an extra column in the join table because it belongs to the relationship between the two entities and not either entity in particular), or put other (often role-based) metadata on a relationship - the community_profile_membership table has a level column noting whether the member is also a moderator, for example. So far, I've been building stuff manually using apollo tools and with facebook's dataloader library to reduce the number of queries needed to fulfill the request (most common query scenarios end up with three total queries, one for the root object, one for the relationships, and one to inflate the relationship values). Naturally, this could be fewer if I took postgraphile's approach. Are there plans for building hmabtm style relationships into postgraphile?