0

We've ran into an issue where we have the db backed up, but migrations got out of sorts and as a result there are a lot of GraphQL queries in our frontend code that don't match up to the db relationships at all.

I'm new to the project, but it looks like people were just making changes in the Hasura console instead of via the CLI and committing migrations.

I'm going through and recreating relationships manually so they match up with the GraphQL queries in the frontend, but moving forward I'd like to ensure this doesn't happen again.

We'd also prefer to move everything from our Docker image on Heroku to Hasura Cloud if possible.

My question is:

Is there a standardized pattern for ensuring the db data, the db schema, and the Hasura [preferably Hasura Cloud] metadata are all version controlled?

Moreover, is there a way to enforce that pattern so other devs can't simply tweak things in Hasura Console and everything gets out of sync again.

Thank you so much in advance if you can help. ‍♂️

corysimmons
  • 7,296
  • 4
  • 57
  • 65

1 Answers1

0

https://hasura.io/blog/moving-from-local-development-staging-production-with-hasura/ is a good place to start.

I’d strongly encourage following that. Running Hasura locally through Docker is really easy to set up and hasura console will give you access to a localhost console that syncs your changes with metadata/migration files in your local repo. From there, just commit, review, merge, and take advantage of Hasura Cloud’s GitHub deploy if you can. If not, hasura deploy and a few environment variables are really all you need to roll out changes.

As far as preventing devs from tweaking things in the console, if you’re talking about some deployed shared environment then honestly I think access to the console should be limited.

nickpassarella
  • 241
  • 1
  • 2