Jak se dělá verzování ve GraphQL?

Takže k tomu verzování v GraphQL. Ono to funguje trochu jinak než u REST, kde jsou verze často vidět v URL. V GraphQL většinou se snažíš udělat schéma tak, aby bylo co nejvíc zpětně kompatibilní. To znamená, že když přidáš nový field nebo typ, nemělo by to rozbít stávající dotazy. Je dobré dodržovat principy jako "nepřepisovat" a "neodstraňovat" existující pole, takže když něco přidáš, je to v pohodě. Když bys chtěl změnit strukturu dat, můžeš třeba vytvořit nový typ a ten starý nechat jak je, dokud na něj lidi stále spoléhají. Někteří lidé používají i namespace pro pole nebo typy, aby si oddělili různé verze. Takže spíš jde o to mít dobře navržené schéma a myslet na to, jak to ovlivňuje ostatní uživatele API. Best practices? No, testovat změny a pořádně dokumentovat co se mění. Když to uděláš dobře, tak se nemusíš bát, že by ti to rozbilo aplikace.

Verzování v GraphQL je fakt jiný, než v REST. Většinou se to řeší spíš tím, že se snažíš udržet zpětnou kompatibilitu, než abys dělal verze jako /v1 nebo /v2. Když chceš přidat nový field nebo udělat změny, tak je důležitý mít na paměti, že bys měl přidávat nové fields místo toho, abys ty starý měnil nebo mazal. Klienty to nijak neovlivní, pokud starý fields zůstanou. Takže můžeš klidně rozšířit schéma a neřešit verzování.

Pokud bys ale potřeboval úplně jinou strukturu dat a chtěl bys to udělat radikálně jinak, pak už bys mohl zvážit vytvoření nového schématu. Ale to je spíš extrémní případ. Další věc je dokumentace – měj ji aktuální a jasnou, aby si vývojáři věděli rady i s novinkama. Taky se mluví o "depreaci" fields, když víš, že něco bude brzy neaktuální – to dává lidem čas na přechod. Zkrátka se snaž držet stávající strukturu co nejvíc a přidávat nové věci tak, aby starý funkce zůstaly. To by mělo pomoct vyhnout se problémům.

Verzování v GraphQL je fakt jiný než v REST. Většinou se nesnažíš dělat nové verze jako s URL. Místo toho se snažíš udržet zpětnou kompatibilitu. Když potřebuješ přidat nový field nebo změnit strukturu, tak to děláš způsobem, který neovlivní stávající query. Třeba můžeš přidat nová pole jako volitelná a staré necháš jak jsou. Takže když někdo volá starší verzi, nic se mu nezmění.

Můžeš mít víc typů, ale většinou to není potřeba. Důležitý je dodržovat principy zpětné kompatibility – jestliže něco vyhodíš nebo změníš, mělo by to být hodně promyšlený.

Best practices jsou třeba udržovat dokumentaci aktuální, testovat změny a myslet na to, že klienti můžou používat různé verze najednou. V podstatě se snaž udržet API stabilní a neudělat zbytečně moc velký změny najednou. Takže v podstatě se neboj experimentovat, ale pamatuj na uživatele tvého API.