Jako mnoho softwarových inženýrů mám hobby projekt. Je to webová stránka ninjawars.net, spuštěná kolem roku 2003 a já na ní hackuji a vydávám nové funkce po celá desetiletí.
Refaktorování hry založené na prohlížeči
Vzhledem k tomu, že navrhuji webové aplikace profesionálně na plný úvazek od roku 2007 a v současné době pracuji hlavně v Reactu a AWS bez serveru, pracuji na převodu stávajících aplikací a her založených na prohlížeči na React pomocí Amplify bez serveru. Zde je letmý pohled na starší verzi 1:
Na subdoméně webu vyvíjím náhradu React + Amplify (+ DynamoDB + Cognito + Lambda) za starší aplikaci PHP + jQuery + Postgresql. Zde je snímek domovské stránky webu založeného na Reactu (umožňující rozvržení přívětivější pro mobily a použití Material-ui jako základu pro vývoj založený na komponentách).
Zachování chování
Existuje mnoho funkcí, funkcí a chování, které je třeba nahradit, a paradigmata současného webu (hoštěného EC2) a přístupu lambda bez serveru nemohou být dále od sebe. Zde je například snímek části obsahu, který je třeba nahradit:
...což zahrnuje hodně náročného back-endového chování. Útok na jiného ninju například spustí smyčku bojového kola, která přitahuje širokou škálu přispívajících faktorů. Můžete používat předměty, bojové dovednosti a v tradičním smyslu jrpg střetávat hitpointy proti hitpointům.
Boj může být jedno kolo, nebo to mohou být desítky kol s různými předměty/dovednostmi, které se berou v úvahu pro každé.
Porovnání jablek a pomerančů
V tradičním monolitu je toto vše v kurzu. Můžete napsat své uživatelské rozhraní jako pohled, ale do řadičů vložíte spoustu logiky, částečně proto, že uživatelské rozhraní, směrování a základní logika jsou vzájemně propojeny. To má své pro a proti:
- Jednou z výhod dokonce i bez serverů je, že je snazší zajistit a uzákonit oddělení mezi uživatelským rozhraním a logikou backendu. V monolitu, zejména s php, dokonce i se šablonovým systémem mají oba tendenci se prolínat.
- Je tu také výkon a cena. Aplikace, která se jako první dostane do cloudfront a má omezené provozní náklady za nevyužitou minutu, je po desetiletí mnohem levnější než neustále běžící hromada instancí EC2.
- Ve skutečnosti ne, náklady:Domnívám se, že náklady i na jediný nástroj pro vyrovnávání zátěže pro směrování do těchto instancí EC2 mohou nakonec způsobit větší rozpočtový zásah než ekosystém bez serveru, a to na základě toho, jak se rozdíly v nákladech během vývoje vyvíjely .
- Dobře, zde je však nevýhoda, která není nepodstatná:Monolity se snáze koncipují a snáze se pěstují. Existuje důvod, proč tolik vývojářů začíná na svém vlastním serveru a ne na serveru bez serveru. Separace a abstrakce zvyšují složitost. Díky tomu, že máte vše na jednom místě, je integrace konstantní, v dobrém i zlém.
Není kam jít, ale vpřed
Pokud dva přístupy bojují, nakonec vyhraje bezserver, když nic jiného, pak proto, že se paradigma webu posunulo. To, co bylo standardní v roce 2003 (monolit), si v roce 2021 žádá jiný přístup (řekněme statický front-end a mikroslužby s tenkými plátky). V budoucích článcích projdu tímto procesem více, porovnám monolit s mikro, a dostanu se k tomu, jak zůstat motivovaný pro tento proces jako vývojář a jak pomoci uživatelům přežít proces, když mohou existovat dvě rozdělené kódové báze. Jednou součástí tohoto procesu je použití vzoru škrtič-fík (obr. škrtič na obrázku):
Škrticí fíkový vzor umožňuje pozvolné zaškrcení starého monolitu ve prospěch refaktoru, ale bez prudkého přepnutí. O tom, jak to udělám s ninjawars 2, se dostanu v pozdějších částech tohoto článku. Uvidíme se tam.