Zpětná a dopředná kompatibilita

JavaScriptový kód Gmailu je poměrně velký a tak se jeho obnovení na klientech vynucuje jen každé dva týdny. Důsledkem toho je, že každá změna na serveru musí být zpětně kompatibilní – musí fungovat i s dva týdny starým klientem. Často to znamená rozdělit jednu změnu na několik menších. Pokud například chcete přejmenovat nějaký identifikátor posílaný ze serveru, musíte nejprve přidat nový, dva týdny posílat oba a teprve potom smazat ten starý. U zásadnějších změn to samozřejmě bývá složitější.

Tuto praxi bych doporučil při vývoji jakýchkoliv webových aplikací. I když nejde o dlouhoběžící aplikaci jako je Gmail, ale třeba jen obyčejnou stránku, tak vždycky může dojít k tomu, že AJAXový požadavek dostane jiná data, než s kterými počítá klient nahraný při načtení stránky. Obvykle jde jen o nepříjemný edge-case, který se dá vyřešit obnovením stránky, i tak je ale dobré se mu vyhnout. Samozřejmě není nutné čekat dva týdny, u normálních webových stránek stačí řekněme den. U déleběžících aplikací je vhodné vybudovat mechanismus, který klienta po stanovené době obnoví.

Alternativou k tomuto postupu je s každou odpovědí posílat verzi serveru a pokud je klient starší, tak ho obnovit. Pro Gmail ale tento postup není vhodný, protože obnova klienta trvá dlouho a verze se mění často. V praxi zpětně nekompatibilních změn naštěstí není moc.

Dopředná kompatibilita

V Google je vybudovaná dobrá kultura rollbacků. Když je nějaký problém (padající testy, nárůst nezachycených výjimek, pokles výkonnosti, …), tak se rychle vrátí poslední funkční verze a pak se teprve hlouběji zkoumá příčina problému a jeho řešení. Důsledkem toho je, že kód musí být i dopředně kompatibilní – musí fungovat i s budoucí verzí klienta. Může totiž dojít k tomu, že klient načte nový kód, následně dojde k rollbacku a server mu začne vracet starý formát odpovědi. U příkladu přejmenování identifikátoru je tedy potřeba i na straně klienta počítat s tím, že buď přijde jen starý identifikátor, nebo přijdou oba, nebo přijde jen ten nový.

Mimochodem ve Facebooku jsem se setkal spíše s kulturou hotfixů – když nastal nějaký problém, tak bylo snahou ho co nejrychleji identifikovat a vyřešit. Výhodou je, že vývoj jde rychleji dopředu, což je obzvlášť patrné v situaci, kdy na problematické změně závisí ještě něco dalšího. Nevýhodou je, že pokud se problém nepodaří identifikovat správně, tak se musí dělat hotfix hotfixu.

Jakub Vrána, Seznámení s oblastí, 8.12.2014, diskuse: 18 (nové: 0)

Diskuse

Tomáš:

tenhle postup se dá aplikovat nejen na komunikaci js client <--> server, ale i pro jakoukoliv komunikaci v aplikaci. Dobrý kandidátem může být práce s daty v session, db, cache, kdy občas potřebujeme provést nějaké změny ve struktuře.

Nevím, jestli tohle pro hodně projektů není přeoptimalizace a jestli z toho mohou těžit, ale podobnou archikteruru a vzory jsem v poslední době vysvětloval hodně týmům, které narazily do zdi třeba při aplikaci automatického deploymentu, mikroslužeb, migrace live dat/databází či práce s dlouhoběžícími MR úlohami.

Setkal jsem se s těmito problémy již kdysi při práci na .NET klientech, kdy server musel podporovat i několik verzí klientů zpětně a ne vždy to člověk chce řešit právě striktním verzováním requestů.
8.12.2014 00:41:06

Martin:

Firma, která u webové aplikace řeší takovéhl věci je dost ojedinělá.

Většina zastává heslo - když se to rozsype, uživatel si zmáčkne F5! A to i mnohé české banky - je to tam oficiální názor :)
8.12.2014 08:50:26

Kony:

U nás se snažíme jít také cestou rollbacků - myslím že je to pro klienta ta nejlepší cesta. Dokonce při nasazovaní na integrační prostředí se zkouší i jak ten rollback dopadne, ještě před nasazením do produkce - abychom měli jistotu, že rollback "umíme udělat". Je to ale docela opruz, protože se musí vracet nejenom verze aplikace, ale i verze testů aplikace - ať už unit, tak i funkčních v selenium.
8.12.2014 09:12:44

Visitor:

Nemám projekty kde bych předpokládal tisíce uživatelů stále online. Ale jinak pokud potřebuji vyměnit CSS, JS, IMG, ..., tak to dělám tak, že za URL přidám ?v=1, ...

Třeba:
<script src="{$baseUri}js/main.js?v=3" type="text/javascript"></script>

A nemusím řešit, že by se nově příchozím načetla stará verze...
8.12.2014 10:35:31

John:

ale pokud je js aplikace velika tak pri kazde zmene se vsem bude stahovat nova verze. Takze pokud delas caste zmeny (kazdy den/nekolikrat denne) a tva js aplikace je velika tak potom musis resit stejny problem jako v Googlu nebo Facebooku.
8.12.2014 11:34:28

karel:

Jenomže na URL parametry nebere spousta CDN keší žádný ohled...
(reakce na) 8.12.2014 16:45:23

JakubN:

Pridanim ?v=xy numesi byt situace vubec vyresena (CDN, nektere prohlizece). Lepsi je menit nazev souboru /js/main.v2.js.
(reakce na) 8.12.2014 17:30:39

David Grudl:

Které prohlížeče ignorují při kešování parametr v URL?
9.12.2014 17:11:41

ikona Jakub Vrána OpenID:

Osobně jsem si před lety ověřoval, že to nedělá stará Opera. Ale podle mě už to dávno neplatí a jde o FUD. Pokud má někdo aktuální Operu, může to ověřit?
9.12.2014 18:49:28

Eduard:

Opera to už bezproblému zvláda
10.12.2014 18:03:12

ikona Petr Soukup:

Lepší příklad by byl asi API, kde se musí podporovat více verzí současně. Tady to vypadá opravdu spíš na nešťastně navrhnuté cachování (zřejmě z nějakého dobrého důvodu, který neznáme).

Kdyby součástí URL k JS byl hash obsahu, tak se 2 týdny zkrátí na minuty.
8.12.2014 17:29:30

Ondrej:

Důvod známe. Gmail je javascriptová single page aplikace a uživatel tak nemusí udělat reload třeba celý den, ale ajaxové requesty už pojedou na novém backendu.
8.12.2014 22:02:34

ikona Jakub Vrána OpenID:

V článku je jasně uvedeno, že obnovení kódu se častěji nedělá záměrně.
(reakce na) 9.12.2014 04:18:30

NoxArt:

"Alternativou k tomuto postupu je s každou odpovědí posílat verzi serveru a pokud je klient starší, tak ho obnovit. Pro Gmail ale tento postup není vhodný, protože obnova klienta trvá dlouho a verze se mění často. V praxi zpětně nekompatibilních změn naštěstí není moc."

A nešlo by tedy posílat verzi protokolu, pouze verze která by se zvýšila, pokud by se změnily parametry?
8.12.2014 18:28:32

Visitor:

"verze se mění často" - to jako Google mění verzi jen tak pod rukama několikrát denně? Nemají pravidlo alá "max jedna verze denně"?
9.12.2014 00:03:46

ikona Jakub Vrána OpenID:

Smyslem je mít systém navržený tak, aby se nové verze daly nasazovat jakkoliv často. Např. ve Facebooku je pravidelný release dvakrát denně.
9.12.2014 18:41:14

Visitor:

O tom bych si něco rád přečetl... To musí být zajímavý životní cyklus... Jak ho udržet? Jak ho organizovat?

My děláme release 4x do roka, ale pravdou je, že děláme ERP no :)
9.12.2014 19:24:57

ikona Jakub Vrána OpenID:

Třeba http://arstechnica.com/business/2012/04/exclusive-…-engineering/. Ale je to trochu starší, takže se tam píše o releasech jen jednou denně.
10.12.2014 09:55:05

Diskuse je zrušena z důvodu spamu.

avatar © 2005-2025 Jakub Vrána. Publikované texty můžete přetiskovat pouze se svolením autora. Ukázky kódu smíte používat s uvedením autora a URL tohoto webu bez dalších omezení Creative Commons. Můžeme si tykat. Skripty předpokládají nastavení: magic_quotes_gpc=Off, magic_quotes_runtime=Off, error_reporting=E_ALL & ~E_NOTICE a očekávají předchozí zavolání mysql_set_charset. Skripty by měly být funkční v PHP >= 4.3 a PHP >= 5.0.