GraphQL.cz/Fórum/Co všechno mám zvážit při přidávání nové verze GraphQL API?

Co všechno mám zvážit při přidávání nové verze GraphQL API?

Přemýšlím o tom, jak přidat novou verzi našeho GraphQL API a mám několik otázek, které mi vrtají hlavou. Jaké jsou nejlepší praktiky, které bych měl vzít v úvahu při navrhování nové verze? Měl bych se zaměřit na zpětnou kompatibilitu, nebo je lepší implementovat breaking changes a vyčistit starý kód? Jakým způsobem by se měly řešit problémy s verzováním? Je lepší dodržet URL strukturu pro různé verze, nebo to nějak elegantněji vyřešit pomocí hlaviček? Zajímá mě také otázka dokumentace – jak důležité je mít podrobnou dokumentaci pro každou verzi API, aby vývojáři mohli snadno přejít na novou verzi? A co testování? Jak nejlépe testovat nové funkce v rámci API před jejich nasazením do produkce? Jaký je ideální způsob monitorování výkonu a chyb po nasazení nové verze? Mám se obávat možných problémů s cache, když se změní struktura dotazů nebo typy? Co vlastně dělat, pokud se objeví nenadálé problémy po nasazení nové verze? A jak tohle všechno komunikovat našim uživatelům, aby byli na změny dostatečně připraveni? Kdy je správný čas na odhalení nových funkcí a jak zabezpečit, že naši uživatelé budou mít dostatek informací o tom, co se změnilo? Je toho tolik na zvážení a já bych rád slyšel názory ostatních vývojářů, co všechno byste vzali v potaz při přidávání nové verze GraphQL API.

212 slov
2.1 minut čtení
17. 1. 2025
Barbora Benešová
Barbora Benešová

Když se chystáš na novou verzi GraphQL API, měl bys zvážit pár věcí. Zpětná kompatibilita je většinou vděčná, ale pokud se ti fakt hromadí technický dluh, možná bude lepší udělat breaking changes a vyčistit to. Co se týče verzování, URL struktura je klasika, ale můžeš zkusit i hlavičky, pokud chceš být moderní a elegantní. A rozhodně nezapomeň na dokumentaci – každá verze by měla mít jasné popisy, co je novýho, co se změnilo, aby vývojáři mohli snadno migrovat. Testování je základ – jednotkový testy, integrační testy, všechno, co jde. Po nasazení sleduj výkon a chyby, klidně použij nějaké monitoring nástroje. Jakmile změníš strukturu dotazů nebo typy, buď připraven na problémy s cache, to může zkomplikovat život. A když se objeví nějaké problémy po nasazení? Měj připravený rollback plán a buď připraven reagovat. Komunikace s uživateli je důležitá – dej vědět o změnách dopředu a třeba udělej i webinář nebo něco podobnýho. Novinky odkryj včas, aby si lidi mohli zvyknout. To nejdůležitější? Mít vše dobře naplánované a udržovat si přehled o tom, co se děje.

174 slov
1.7 minut čtení
15. 1. 2024
Bohumil Košťál
Bohumil Košťál

Při přidávání nové verze GraphQL API je fajn mít na paměti pár věcí. Zpětná kompatibilita je většinou klíčová, protože se nechceš dostat do situace, kdy ti uživatelé začnou nadávat, že jim něco nefunguje. Na druhou stranu, když máš hodně zastaralý kód, někdy je lepší udělat breaking changes a začít znovu, než se trápit s legacy věcmi. Co se týče verzování, tak URL struktura je klasika, ale hlavičky můžou být elegantnější. K dokumentaci – ta musí být pečlivá a dostatečně jasná, aby vývojáři věděli, co se změnilo a jak to používat. Testování je samozřejmě nutnost a nezapomeň na staging, než to pustíš do produkce. Monitorování výkonu a chyb po nasazení je bezpodmínečně potřeba, ideálně nějaký logovací a sledovací systém. Cache může být problém, hlavně když měníš typy nebo struktury dotazů, tak na to dej pozor. Pokud narazíš na problémy po nasazení, tak mít plán rollbacku se hodí. Komunikace s uživateli je super důležitá – dej jim vědět o novinkách včas a jasně. Oznámkování nových funkcí by mělo vycházet z toho, kdy jsi si jistý, že jsou stabilní a fungují jak mají.

180 slov
1.8 minut čtení
30. 11. 2023
Lukáš Vojtěch
Lukáš Vojtěch

Při přidávání nové verze GraphQL API je toho fakt hodně na zvážení. Zpětná kompatibilita je důležitá, ale někdy se prostě musíš zbavit starého kódu a udělat breaking changes, pokud to zlepší celkovou architekturu. Co se verzování týče, URL struktura bývá jasná, ale přes hlavičky můžeš být elegantnější a snadnější pro uživatele.

Dokumentace je klíčová – každá verze by měla mít pořádnou dokumentaci, aby vývojáři věděli, co se změnilo a co nového mohou použít. Testování je nutnost, ideálně mít nějaké automatizované testy a před nasazením dělat staging. Po nasazení sleduj výkon a chyby, nástroje jako Sentry nebo New Relic ti hodně pomůžou.

Co se cache týče, jo, může to být problém, pokud změníš strukturu dotazů. Měj plán na řešení nenadálých problémů – rollback by měl být vždy možnost. Komunikace s uživateli je taky důležitá, dej jim vědět včas o změnách a co nového mohou očekávat. Každopádně plánuj odhalení funkcí tak, aby měli čas si na to zvyknout.

V podstatě se snaž být transparentní a uživatelé ti za to později poděkují.

167 slov
1.7 minut čtení
26. 9. 2024
Jan Matějka
Jan Matějka
Podobné otázky