Migrace v databázi při používání GraphQL

Myslím, že to záleží na tom, jak velký máš projekt a jak často se mění. Když děláš malý projekt, tak možná není nutné dělat migrace pro každou drobnost, ale u větších věcí je jasný, že to pak může být chaos. S malýma migracema je to fajn, protože vidíš přesně co se kdy změnilo, ale když ti jich naskáče hodně, tak se pak blbě hledají ty starší. Pokud něco pokazíš při migraci, tak s tím pak může bejt problém, zvlášť když máš víc lidí na projektu. Mělo by to být dostatečně dokumentovaný, aby ses rychle zorientoval, co a kdy se dělalo. Takže asi jo, pokud to není zásadní změna, klidně to seskupit a udělat migraci jednou za čas. Ale snaž se udržovat to nějak přehledný.

Když to vezmu z vlastní zkušenosti, tak záleží na projektu a týmu. Já osobně preferuju dělat migrace spíš častěji a menší. Přijde mi to přehlednější a když se něco posere, tak je snazší to opravit. Když uděláš velkou migraci a něco nefunguje, tak pak musíš zpětně hledat, co všechno bylo změněno a to může být peklo.

Na druhou stranu, když máš opravdu drobné změny, tak to může začít být otravné, pokud děláš migraci třeba každý týden. To chci říct, že je dobrý najít nějaký kompromis. Zkus si třeba udržovat nezávislé migrace pro větší věci a pak poslední verzi na drobnosti udělat jednou za čas.

V GraphQL ti pak ty migrace pomůžou udržovat schema synchronizovaný s databází. Pokud ti něco na backendu nefunguje, tak se koukneš na poslední migraci a vidíš, co tam přesně bylo. Ale bacha na to, abys neměl příliš mnoho závislostí mezi migracemi, jinak se ti to složitě sleduje. No a při chybách? Tak řešit rollbacky nebo revize starších verzí je klíčový. Vím, že pro některé týmy je lepší mít jeden velký commit, ale já radši malý a rychlý.

Když jde o migrace v databázi a GraphQL, tak bych to viděl spíš na individuální přístup. Záleží na tom, jak často a jak moc měníš schéma. Pokud děláš drobné úpravy často, můžeš se dostat do chaosu s migracemi, takže to chce najít balanc. Na jednu stranu mít víc malých migrací znamená lepší sledovatelnost změn, ale na druhou stranu to může být v průběhu času otravný a únavný. Méně větších migrací může být praktický, ale pak riskuješ, že se ti nahromadí hodně změn a to může být problém, když se něco posere.

Když se objeví chyby při migraci, je dobrý mít testy na svých modelech a schématech, aby ses ujistil, že všechno funguje jak má. Někdy pomůže mít rollback mechanismus nebo zálohy, abys mohl jednoduše vrátit zpět poslední změny. V kontextu GraphQL je důležité mít dobře definované resolvery a typy, aby migrace neudělaly paseku v API. Takže si myslím, že bys měl experimentovat a najít systém, který ti sedí nejvíc. Jak to vidíš ty?