3 ms·

What I didn't find out while trialing Hasura is if it's possible to declare your GraphQL API using code rather than the Hasura web GUI. I eventually gave up on

by kasbah 6y ago

What I didn't find out while trialing Hasura is if it's possible to declare your GraphQL API using code rather than the Hasura web GUI. I eventually gave up on it because I figured I couldn't store the configuration I was making as code in a git repo. Your comment makes me think I was maybe wrong about that? Could you confirm and/or link to some docs about this aspect?

tango12 6y ago
Everything in Hasura is configured declaratively. The web GUI is essentially just updating that configuration. There are a few options: 1. You use the GUI and then export/import the metadata 2. You can use the GUI and as you do, the GUI will keep incrementally updating the metadata configuration file and even create database migrations for you in your folder on your machine, kind of like an IDE 3. You can stop using the UI altogether, and just write the configuration by hand Docs: https://hasura.io/docs/1.0/graphql/manual/migrations/index.html https://hasura.io/docs/1.0/graphql/manual/migrations/index.h... Also, feel free to ask around on our discord if you need help: https://discord.gg/hasura https://discord.gg/hasura
- adav 6y ago
  This approach means one’s own deployments of Hasura can’t be immutable?
  - tango12 6y ago
    There's a docker image that can take a configuration file as input. https://hasura.io/docs/1.0/graphql/manual/migrations/advanced/auto-apply-migrations.html https://hasura.io/docs/1.0/graphql/manual/migrations/advance... You can choose to bring in that configuration via a Kubernetes configmaps type thing, or by baking a new image for a release (like you would have done with your source code say).
    - adav 6y ago
      Yep, that’s what I’ve been doing for my experiments with Hasura so far :) It just feels a little “off-piste”.
adav 6y ago
I’m experimenting with Hasura for an MVP. Like you I wanted to have the schema config in code and version controlled. The docs are very lacking for this use case. However I think I’ve worked out a decent compromise: - I start configuring the basics of my Hasura setup through the Admin GUI. - I then use the CLI to download the metadata with the command `hasura metadata export`. - Commit that to my repo. - Using the existing metadata files as a template, make any changes when required. - Use the cli-migrations docker image to apply my metadata on each deployment of Hasura (as detailed here: https://hasura.io/docs/1.0/graphql/manual/migrations/advanced/auto-apply-migrations.html https://hasura.io/docs/1.0/graphql/manual/migrations/advance...) Not sure if that’s the most efficient way to do it but it seems to work and it was pretty quick to setup.
dmitryminkovsky 6y ago
All your configuration is stored in a YAML file (https://hasura.io/docs/1.0/graphql/manual/migrations/index.html https://hasura.io/docs/1.0/graphql/manual/migrations/index.h...). You can do your work in the UI, and then export the YAML file to see what you did. You can/should commit that file. I don't believe its data structures are documented (perhaps at https://hasura.io/docs/1.0/graphql/manual/api-reference/index.html https://hasura.io/docs/1.0/graphql/manual/api-reference/inde...), but its format is pretty straightforward, especially once you've used the GUI for a while.
ivome 6y ago
Have you looked at Slicknode? Slicknode allows you to declaratively define your application with schema etc. in your local code and then just sync with a CLI. It then does database migrations and updates/provisions a serverless API on AWS (with Lambda, Aurora Serverless). That way you can leverage proper version control, merge feature branches, do copy paste of parts of models, reuse entire modules across projects, etc. Slicknode: https://slicknode.com https://slicknode.com Github: https://github.com/slicknode/slicknode https://github.com/slicknode/slicknode (I'm from Slicknode)

by kasbah 6y ago

tango12 6y ago

Everything in Hasura is configured declaratively. The web GUI is essentially just updating that configuration. There are a few options: 1. You use the GUI and then export/import the metadata 2. You can use the GUI and as you do, the GUI will keep incrementally updating the metadata configuration file and even create database migrations for you in your folder on your machine, kind of like an IDE 3. You can stop using the UI altogether, and just write the configuration by hand Docs: https://hasura.io/docs/1.0/graphql/manual/migrations/index.html https://hasura.io/docs/1.0/graphql/manual/migrations/index.h... Also, feel free to ask around on our discord if you need help: https://discord.gg/hasura https://discord.gg/hasura

adav 6y ago
This approach means one’s own deployments of Hasura can’t be immutable?
- tango12 6y ago
  There's a docker image that can take a configuration file as input. https://hasura.io/docs/1.0/graphql/manual/migrations/advanced/auto-apply-migrations.html https://hasura.io/docs/1.0/graphql/manual/migrations/advance... You can choose to bring in that configuration via a Kubernetes configmaps type thing, or by baking a new image for a release (like you would have done with your source code say).
  - adav 6y ago
    Yep, that’s what I’ve been doing for my experiments with Hasura so far :) It just feels a little “off-piste”.

adav 6y ago

I’m experimenting with Hasura for an MVP. Like you I wanted to have the schema config in code and version controlled. The docs are very lacking for this use case. However I think I’ve worked out a decent compromise: - I start configuring the basics of my Hasura setup through the Admin GUI. - I then use the CLI to download the metadata with the command `hasura metadata export`. - Commit that to my repo. - Using the existing metadata files as a template, make any changes when required. - Use the cli-migrations docker image to apply my metadata on each deployment of Hasura (as detailed here: https://hasura.io/docs/1.0/graphql/manual/migrations/advanced/auto-apply-migrations.html https://hasura.io/docs/1.0/graphql/manual/migrations/advance...) Not sure if that’s the most efficient way to do it but it seems to work and it was pretty quick to setup.

dmitryminkovsky 6y ago

All your configuration is stored in a YAML file (https://hasura.io/docs/1.0/graphql/manual/migrations/index.html https://hasura.io/docs/1.0/graphql/manual/migrations/index.h...). You can do your work in the UI, and then export the YAML file to see what you did. You can/should commit that file. I don't believe its data structures are documented (perhaps at https://hasura.io/docs/1.0/graphql/manual/api-reference/index.html https://hasura.io/docs/1.0/graphql/manual/api-reference/inde...), but its format is pretty straightforward, especially once you've used the GUI for a while.

ivome 6y ago

Have you looked at Slicknode? Slicknode allows you to declaratively define your application with schema etc. in your local code and then just sync with a CLI. It then does database migrations and updates/provisions a serverless API on AWS (with Lambda, Aurora Serverless). That way you can leverage proper version control, merge feature branches, do copy paste of parts of models, reuse entire modules across projects, etc. Slicknode: https://slicknode.com https://slicknode.com Github: https://github.com/slicknode/slicknode https://github.com/slicknode/slicknode (I'm from Slicknode)