Existuje nějaký standard pro verzování GraphQL API?

Když se bavíme o verzování GraphQL API, tak to je trochu jiný level než u REST. Většina lidí říká, že GraphQL je vlastně navrženo tak, aby se dalo rozvíjet bez nutnosti verzování. To znamená, že můžeš přidávat nové pole a typy, aniž bys musel vymýšlet novou verzi. Klíčové je zachovat zpětnou kompatibilitu – staré dotazy by měly pořád fungovat, i když přidáš nový fukce nebo pole.

Jasně, občas se stane, že musíš nějaké věci změnit nebo odstranit, ale většinou se to dá udělat tak, že staré dotazy prostě ponecháš aktivní a přidáš nové. Také můžeš používat direktivy nebo deprecated tagy pro označení toho, co už je staré a co se bude měnit. S tím pak můžeš varovat uživatele API, že by se měli začít dívat na novější věci.

Myslím si, že nejlepší přístup je mít jednu URL a spravovat změny přímo ve schématu. To umožňuje větší flexibilitu a méně chaosu s vícero endpointy. Některé příklady dobré praxe zahrnují dokumentaci změn v API a pravidelnou komunikaci s uživateli API ohledně plánovaných změn. Takhle se vyhnout zmatku a můžeš udržet všechno pěkně v chodu.

Takže, pokud jde o verzování GraphQL API, většina lidí tvrdí, že bys neměl potřebovat verze jako u REST. Důvod je ten, že GraphQL je víc flexibilní. Můžeš přidávat nové typy a pole bez ovlivnění stávajících dotazů. Obvykle se doporučuje mít jeden endpoint a spravovat změny ve schématu. Když potřebuješ něco změnit nebo přidat, tak se to udělá tak, aby to bylo zpětně kompatibilní. To znamená, že staré dotazy by měly pořád fungovat, dokud opravdu nepřijdeš s nějakou zásadní změnou.

Jasně, někdy je potřeba udělat breaking changes, ale na to se dá připravit. Například můžeš deprekovat pole nebo typy, ale nechat je nějakou dobu aktivní, aby si měli vývojáři čas přizpůsobit svoje dotazy. Je dobrý mít dokumentaci k tomu, co se mění a jaké jsou novinky.

V praxi to pak vypadá tak, že když chceš něco nového, prostě to přidáš do schématu a lidé si toho můžou všimnout a začít používat nové dotazy. Můžeš třeba i použít direktivy k označení starých funkcí jako deprecated a tím dát vědět, že už bys je neměl používat.

V podstatě to chce jen opatrnost a plánování předem. A když už opravdu musíš dělat zásadní změny, tak třeba zvážit možnost zavést novou verzi API v rámci stejný URL s prefixem nebo podobně.

U GraphQL API se verzování obvykle neřeší tak jako u REST. Místo toho je doporučeno pracovat na evoluci schématu tak, aby bylo zpětně kompatibilní. To znamená, že když přidáš nové pole nebo typ, měl bys zajistit, že staré dotazy pořád fungují. Nové funkce můžeš přidávat bez toho, abys musel měnit existující endpointy, což je výhoda GraphQL.

Některé firmy používají prefixy pro nové verze, ale to obvykle není nutné. V praxi se ale může stát, že pokud uděláš zásadní změnu ve schématu (např. odstraníš existující pole), tak už to začne být problém. Proto je dobré udržovat staré dotazy funkční co nejdéle a používat deprecated tagy na poli, které plánuješ odstranit. Pokud jde o příklady dobré praxe, doporučuji se podívat na projekty jako Apollo nebo Relay, ty mají docela slušné návody a příklady jak s tímhle pracovat.