thank you for the summary I get a bit lost starting using Hasura CLI... carry on the good work : always someone , somewhere and someday will search for your upcoming tutorials and will find it as life saver !
Thank you. I was swayed by old samples that didn't actually work. I arrived at this video and came across a working sample of authentication and authorization. I'm going to read the code to get a deeper understanding.
Incredible tutorial, thank you. Not sure if it's a latest-update from Hasura, but I didn't need to mark my initial migration as already-applied. It was already marked in the migration history it seems(?). Regardless, fantastic job explaining this. The official documentation should just link to this video :-)
thanks, make more! I have a misunderstanding with replacing data from one db to another through hasura. Is there a way to import and export not only medatada, but also all data from another db clone?
Glad you enjoyed it! To answer your question - don't forget that Hasura simply provides a GraphQL layer over the top of a standard database schema. So, if you want to clone the database, you can simply export the data directly from the SQL database itself (e.g., if it's a Postgres database, using pg_dump). You can then choose which tables to track in Hasura to be part of the GraphQL API. The first video in the series should help explain that a little more. Hope that helps!
Nice video, thank you! Unfortunately you didn't show how to keep migrations and metadata in-sync manually. Hasura documentation around migrations and metadata sucks. Each command should have explanations on what it affects: local files, metadata files, metadata table, etc. No word on that and you can only guess or experiment yourself. E.g. after a down migration you have to restore consistency between both "sources of truth". Hasura will rely on metadata which now may describe removed tables, columns, etc. How would you fix that? Editing metadata files and applying them with 'medata apply' (like it's shown) is error prone - you can easily introduce a new mismatch that will be even harder to remove later. There's 'metadata inconsistency drop' with many other commands. None is properly documented. Now add bugs to the mix. E.g. 'metadata export' does not remove table descriptions that were removed. And now you see why the entry barrier of this tool is still way too high. It takes weeks to learn (which is worth it, IMO, but not all developers or teams have that much time to invest).
the best hasura course out there, finished the playlist today and learnt so much through the journey thanks very much 😘😘😘
thank you for the summary I get a bit lost starting using Hasura CLI... carry on the good work : always someone , somewhere and someday will search for your upcoming tutorials and will find it as life saver !
Great tutorials. Worth to subscribe your channel
Hey I just recently found these, you should make more videos!
You are very succinct and to the point and its great
Thanks for this video! ☺
Amazing tutorial thanks. I'd love to see best practices to apply to staging and production. And also could mention squashing migrations too.
Thank you. I was swayed by old samples that didn't actually work. I arrived at this video and came across a working sample of authentication and authorization. I'm going to read the code to get a deeper understanding.
Excellent series, thanks 🙏
Incredible tutorial, thank you.
Not sure if it's a latest-update from Hasura, but I didn't need to mark my initial migration as already-applied. It was already marked in the migration history it seems(?).
Regardless, fantastic job explaining this. The official documentation should just link to this video :-)
Yes, the latest Hasura auto-applies 'create --from-server' kind of migrations.
could you do a video on how to create computed fields?
thanks, make more!
I have a misunderstanding with replacing data from one db to another through hasura.
Is there a way to import and export not only medatada, but also all data from another db clone?
Glad you enjoyed it!
To answer your question - don't forget that Hasura simply provides a GraphQL layer over the top of a standard database schema. So, if you want to clone the database, you can simply export the data directly from the SQL database itself (e.g., if it's a Postgres database, using pg_dump). You can then choose which tables to track in Hasura to be part of the GraphQL API. The first video in the series should help explain that a little more. Hope that helps!
@@cloudspeak thanks, i did the same) and then read your hint. It is a helpful answer for others!
admin scret should como from .env files
Yep. Because hasura folder will go under Git so you shouldn' store secrets there.
Nice video, thank you! Unfortunately you didn't show how to keep migrations and metadata in-sync manually. Hasura documentation around migrations and metadata sucks. Each command should have explanations on what it affects: local files, metadata files, metadata table, etc. No word on that and you can only guess or experiment yourself.
E.g. after a down migration you have to restore consistency between both "sources of truth". Hasura will rely on metadata which now may describe removed tables, columns, etc. How would you fix that? Editing metadata files and applying them with 'medata apply' (like it's shown) is error prone - you can easily introduce a new mismatch that will be even harder to remove later. There's 'metadata inconsistency drop' with many other commands. None is properly documented.
Now add bugs to the mix. E.g. 'metadata export' does not remove table descriptions that were removed. And now you see why the entry barrier of this tool is still way too high. It takes weeks to learn (which is worth it, IMO, but not all developers or teams have that much time to invest).