Hasura migrations [GraphQL engine, pragmatic overview, 2020]

🎉 Get complete 6,5 Hours Video Course about Hasura for the lowest possible price 🎉
🎁 20%-off with HASURA-EASY-START code: bit.ly/complet...
In this video tutorial we will learn what are migrations in Hasura GraphQL engine, how to use them and why it is very important for your Hasura project. We will see how to create initial migration () and how to create other migrations automatically once you change you database scheme in Hasura console. As a bonus you will see how easy to upgrade your Hasura version and how to configure your server to not always provide annoying flags in terminal. I hope this video you will find useful and please leave you feedback in comments. Thank you for your attention and enjoy watching :)
✅ Check out my videos about Angular Material Library: • Angular Material
✅ And there are some topics about Angular Material CDK:
• Angular Material CDK
✅ Quick subscribe: / @decodedfrontend
🔗 Links:
Hasura's home page:
hasura.io
Link to Github repo:
github.com/mez...
How to install Hasura CLI:
hasura.io/docs...
Auto-Apply Hasura container:
hasura.io/docs...

[@DecodedFrontend]

🎉 If you just started with Hasura GraphQL you can save a lot of time learning it
You can watch my complete (6,5 Hours) video course on bit.ly/complete-hasura-course where you will learn how to: Connect React & Angular Apps with Hasura, Implement Authentication & Role-Based access to the Data, File Uploading, extend Business Logic with Firebase Cloud Function and how to Deploy your Project to multi Environments (dev, prod) with GitHub Actions.

[@jorgeespinoza9294]

probably the best option for the init migration is not to delete it but to mark it as applied on the server:
hasura migrate apply --version "" --skip-execution

[@DecodedFrontend]

thank you for a hint! Unfortunately I have no chance to check your suggestion but at the glance I am pretty sure that your solution would work out 😉

[@bo3oof]

this's very helpful, thanks

[@VolodymyrDmytrenko64]

- Те, що треба. Дякую!!!

[@DecodedFrontend]

Радий, що сподобалось! :)

[@cuongdev]

Thanks for explaining about squash migration

[@DecodedFrontend]

My pleasure :)

[@boot-strapper]

ok but to be clear having a lot of migration files is kind of the point, and you should never ever squash them - especially in prd.

[@DecodedFrontend]

Hi,
Thanks for feedback! :)
I see nothing bad with squashing migrations which belong to one particular feature. I would even encourage to do it because it is more maintainable and you immediately see intention of every migration.

[@boot-strapper]

@@DecodedFrontend smashing all the migrations together will help with the intent of each one? Each migration should be doing a single thing, that way if you break something you can easily roll back that single thing..

[@DecodedFrontend]

Not all migrations together but only migrations which represent certain feature. So you get feature-1-migration-file, feature-2-migration-file, ... etc. As example imagine you develop some feature. You created a table for it, then you decided to change the table column name and realized that you made a typo and renamed it again, then you might need to change the type of some column several times . So you get at least 4 migrations which would make sense during feature development but once the feature is done you do not need all those intermediate migrations where you fix typos in column etc you are interested only in one final migration which represents the final dB scheme of this particular feature (not the whole app). It also easier to rollback changes because if something goes wrong you revert a whole feature rather then 1/4 or half of it. Think about it like with GIT commits, when you develop feature in feature branch you may have a lot of commits but once you merge it to master/develop you most probably squash them in one commit, so your master/develop stays lean and contains only feature commits and bugfixes. The same story with migration squashing here.