Nope. This is kind of by design. Hasura aims to expose a very light, high-performance abstraction with self-contained access control (you can specify access control based on any relationship in the schema).
For any customisation, there are 2 options:
1) Use schema-stitching on the client-side
2) Write a graphql proxy that proxies to Hasura's graphql engine
In most cases, 2 will never be required or be fruitful, because the access control pain will keep increasing as the schema size increases!
Custom resolvers will also usually not be required because of Postgres views. Are there any specific use-cases you're thinking about?
Unfortunately, we don't have subscriptions yet. Most subscriptions implementations are not very useful because they don't handle the state initialisation or atleast-once semantics. Furthermore, add access control to subscriptions and you basically have zero performance. Firebase has a local database which is kept in sync (and handles these problems underneath) which is probably the only way of exposing this functionality "neatly" to frontend developers. Do you have any specific requirements around subscriptions? Would love to hear your inputs!
> Can I stick Hasura in front of my existing Postgres Db? Can I use my own migration tool?
We have internal tooling to make that happen on request on the paid tiers, but the experience is not smooth enough for it to be generally available as a feature yet. Currently, the best way to try out your existing schema is to `pg_dump` and `psql` into Hasura's postgres.
Yes you can use your own migrations! All you will need to do is add metadata to tell Hasura's graphQL engine to "track" whatever tables you add through your own tools. Hasura's migration tooling is inspired from rail's tooling and is essentially raw SQL. We'll be adding more docs and sample use-cases in the days to come!
