Wydawnictwo Helion
ul. Koœciuszki 1c
44-100 Gliwice
tel. [phone]

e-mail: [e-mail]

Skalowalne witryny internetowe.
Budowa, skalowanie i optymalizacja
aplikacji internetowych nowej generacji

Autor: Cal Henderson
T³umaczenie: Miko³aj Szczepaniak
ISBN: 978-83-246-0723-5
Tytu³ orygina³u:

Building Scalable Web Sites:

Building, scaling, and optimizing the next
generation of web applications

Format: B5, stron: 400

Naucz siê tworzyæ aplikacje internetowe nowej generacji

i do³¹cz do nurtu Web 2.0

•

Chcesz tworzyæ bardziej wydajne aplikacje internetowe?

•

Chcesz poznaæ zasady projektowania skalowalnych architektur?

•

Chcesz efektywnie zarz¹dzaæ danymi w aplikacjach internetowych?

Oblicze internetu podlega nieustannym zmianom. Obecnie coraz czêœciej obok
klasycznych witryn internetowych pojawiaj¹ siê aplikacje internetowe, które
charakteryzuj¹ siê odseparowaniem warstwy danych od warstwy prezentacji. Zmiana
modelu programowania wymaga przygotowania odpowiedniej platformy sprzêtowej
i programowej oraz zaprojektowania nowego systemu obs³ugi danych. Zastosowanie
przy wykonywaniu tych zadañ sprawdzonych strategii wykorzystywanych przez
pionierów tworz¹cych aplikacje internetowe nowej generacji pozwoli Ci zaoszczêdziæ
czas i koszty.
Ksi¹¿ka

„

Skalowalne witryny internetowe…

”

to zaawansowany i wszechstronny

przegl¹d zagadnieñ zwi¹zanych z budowaniem takich w³aœnie aplikacji internetowych.
Pomo¿e Ci ona w rozwi¹zaniu problemów i unikniêciu pu³apek czyhaj¹cych na
programistów witryn internetowych nowej generacji. Poznasz sprawdzone strategie
projektowania architektury oprogramowania, przygotowywania œrodowiska
programistycznego, zapewniania niezawodnoœci aplikacji czy wydajnego zarz¹dzania
informacjami. Dowiesz siê tak¿e, jak tworzyæ skalowalne i ³atwe w konserwacji witryny,
które bêd¹ zapewniaæ komfort pracy niezale¿nie od up³ywu czasu i wzrostu liczby
u¿ytkowników.

•

Projektowanie architektury aplikacji internetowych

•

Przygotowywanie œrodowiska programistycznego

•

Tworzenie aplikacji wielojêzycznych

•

Zarz¹dzanie bazami danych

•

Integrowanie poczty elektronicznej z witrynami

•

Stosowanie us³ug zdalnych

•

Wykrywanie i rozwi¹zywanie problemów z wydajnoœci¹

•

Skalowanie aplikacji internetowych

•

Monitorowanie funkcjonowania aplikacji

•

Korzystanie z interfejsów API

3

Spis tre

ļci

Przedmowa ......................................................................................................................7

1. Wprowadzenie .............................................................................................................. 15

Czym jest aplikacja internetowa?

15

Jak budujemy aplikacje internetowe?

16

Czym jest architektura?

17

Od czego naleĔy zaczñè?

18

2. Architektura aplikacji internetowej ............................................................................. 21

Wielowarstwowa architektura oprogramowania

21

Technologie wielowarstwowe

24

Projektowanie interfejsów programowych

27

Droga od punktu A do punktu B

29

Podziaä na oprogramowanie i sprzöt

31

Platformy sprzötowe

31

Rozwój platformy sprzötowej

36

NadmiarowoĈè sprzötu

39

Sieè

40

Jözyki, technologie i bazy danych

43

3.

Ļrodowiska wytwarzania oprogramowania...............................................................45

Trzy naczelne zasady

45

Kontrola kodu Ēródäowego

46

Kompilacja w jednym kroku

66

ćledzenie bäödów

77

Skalowanie modelu wytwarzania aplikacji

85

Standardy kodowania

86

Testowanie

89

4

_

Spis tre

ļci

4. i18n, L10n i Unicode........................................................................................................93

Umiödzynarodowienie i lokalizacja oprogramowania

94

Unicode w piguäce

98

Schemat kodowania UTF-8

104

Schemat kodowania UTF-8 w aplikacjach internetowych

105

Stosowanie schematu kodowania UTF-8 w jözyku PHP

107

Stosowanie schematu kodowania UTF-8 w pozostaäych jözykach programowania

108

Stosowanie schematu kodowania UTF-8 w bazach danych MySQL

109

Stosowanie schematu kodowania UTF-8 w wiadomoĈciach poczty elektronicznej

111

Stosowanie schematu kodowania UTF-8 w skryptach jözyka JavaScript

113

Stosowanie schematu kodowania UTF-8 w interfejsach API

115

5. Integralno

ļë danych i bezpieczeħstwo .......................................................................117

Strategie zapewniania integralnoĈci danych

117

Dobre, prawidäowe i nieprawidäowe

119

Filtrowanie sekwencji UTF-8

120

Filtrowanie znaków sterujñcych

126

Filtrowanie kodu HTML

127

Ataki XSS

131

Wstrzykiwanie kodu jözyka SQL

140

6. Poczta elektroniczna ................................................................................................... 147

Otrzymywanie wiadomoĈci poczty elektronicznej

147

Ryzyko wstrzykiwania wiadomoĈci poczty elektronicznej do naszej aplikacji

150

Format MIME

152

Analiza skäadniowa prostych wiadomoĈci MIME

154

Analiza skäadniowa zaäñczników zakodowanych w trybie UU

156

Zaäñczniki w formacie TNEF

157

Dlaczego technologie bezprzewodowe nie lubiñ programistów?

159

Zbiory znaków i schematy kodowania

162

Rozpoznawanie uĔytkowników

164

Testy jednostkowe

167

7. Us

ĥugi zdalne................................................................................................................169

Klub usäug zdalnych

169

Gniazda

170

Stosowanie protokoäu HTTP

173

NadmiarowoĈè usäug zdalnych

179

Systemy asynchroniczne

182

Wymiana danych w formacie XML

187

Lekkie protokoäy

192

Spis tre

ļci

_

5

8. W

éskie gardĥa .............................................................................................................. 197

Identyfikowanie wñskich gardeä

197

Operacje wejĈcia-wyjĈcia

212

Usäugi zewnötrzne i czarne skrzynki

225

9. Skalowanie aplikacji internetowych .......................................................................... 241

Mit skalowania

241

Skalowanie sieci

253

RównowaĔenie obciñĔeþ

256

Skalowanie bazy danych MySQL

272

Replikacja baz danych MySQL

278

Partycjonowanie bazy danych

287

Skalowanie wielkich baz danych

292

Skalowanie pamiöci masowej

294

Pamiöè podröczna

302

Skalowanie w piguäce

305

10. Statystyki, monitorowanie i wykrywanie usterek ....................................................307

ćledzenie statystyk aplikacji internetowej

307

Monitorowanie aplikacji

318

Alarmowanie

336

11. Interfejsy API................................................................................................................339

Kanaäy danych

339

Technologie mobilne

352

Usäugi sieciowe

356

Warstwy transportowe interfejsów API

359

NaduĔywanie interfejsów API

367

Uwierzytelnianie

371

PrzyszäoĈè

375

Skorowidz .................................................................................................................... 377

15

ROZDZIA

Ĥ 1.

Wprowadzenie

Zanim przystñpimy do projektowania i kodowania naszych przykäadów, musimy zrobiè krok
wstecz i zdefiniowaè najwaĔniejsze terminy. Warto siö zastanowiè, jaki jest cel naszych rozwaĔaþ
i czym ten cel siö róĔni od tego, co robiliĈmy do tej pory. Czytelnicy, którzy budowali juĔ jakieĈ
aplikacje internetowe, mogñ pominñè kolejny rozdziaä, poniewaĔ prezentowany tam materiaä
bödzie obejmowaä wiedzö podstawowñ. Z drugiej strony, czytelnicy zainteresowani ogólnym
kontekstem naszych rozwaĔaþ koniecznie powinni siö zapoznaè takĔe ze wspomnianym roz-
dziaäem 2.

Czym jest aplikacja internetowa?

WiökszoĈè czytelników tej ksiñĔki najprawdopodobniej doskonale zdaje sobie sprawö z tego,
czym jest aplikacja internetowa, co wcale nie oznacza, Ĕe próba precyzyjnego zdefiniowania
tego terminu jest bezcelowa, poniewaĔ etykieta aplikacji internetowej bardzo czösto jest przypi-
sywana róĔnym rozwiñzaniom w sposób bäödy. Aplikacja internetowa nie jest ani witrynñ
internetowñ, ani aplikacjñ w rozumieniu typowego uĔytkownika systemu operacyjnego.
Aplikacja internetowa plasuje siö gdzieĈ pomiödzy tymi dwoma rozwiñzaniami i me pewne
cechy zarówno witryny internetowej, jak i autonomicznej aplikacji.

O ile witryna internetowa zawiera strony z danymi, o tyle aplikacja internetowa skäada siö
zarówno z danych, jak i odröbnego mechanizmu ich dostarczania do przeglñdarki. Podobnie
jak entuzjaĈci duĔej dostöpnoĈci witryn internetowych zachwycajñ siö moĔliwoĈciñ oddzielania
znaczników od stylów za pomocñ plików CSS, równieĔ projektanci aplikacji internetowych
szczycñ siö moĔliwoĈciñ faktycznego oddzielania danych od warstwy prezentacji — dane aplikacji
internetowej nie majñ nic wspólnego ze znacznikami (choè same mogñ tego rodzaju elementy
zawieraè). Komunikaty skäadajñce siö na komponent aplikacji internetowej sñ odseparowane
od znaczników. Oznacza to, Ĕe w razie koniecznoĈci wyĈwietlenia tych danych uĔytkownikowi
naleĔy wyodröbniè odpowiednie komunikaty z miejsca ich skäadowania (najczöĈciej z bazy
danych), po czym dostarczyè uĔytkownikowi w okreĈlonym formacie i za poĈrednictwem jakie-
goĈ medium (najczöĈciej w formacie HTML i za poĈrednictwem protokoäu HTTP). Najciekawsze
jest jednak to, Ĕe nie musimy dostarczaè danych w formacie HTML — równie dobrze mogli-
byĈmy je wysyäaè w pliku PDF za poĈrednictwem np. poczty elektronicznej.

Aplikacje internetowe nie zawierajñ stron w rozumieniu znanym z witryn internetowych, które
z natury rzeczy skäadajñ siö ze stron internetowych. O ile aplikacja internetowa moĔe prezentowaè
swoje dane np. za poĈrednictwem dziesiöciu stron internetowych, dodawanie kolejnych danych

16

_

Rozdzia

ĥ 1. Wprowadzenie

moĔe zwiökszyè tö liczbö bez koniecznoĈci tworzenia nowych szablonów jözyka HTML ani
dopisywania kodu Ēródäowego samej aplikacji. PoniewaĔ aplikacja internetowa moĔe oferowaè
takie funkcje jak przeszukiwanie (na podstawie säów wpisywanych przez uĔytkowników),
liczba generowanych „stron internetowych” w praktyce moĔe byè nieograniczona, co oczywiĈcie
nie oznacza, Ĕe musimy w nieskoþczonoĈè dopisywaè niezbödny kod HTML-a. Stosunkowo
niewielki zbiór szablonów i logika generowania dynamicznej zawartoĈci pozwala nam na
tworzenie niezbödnych stron na bieĔñco, w odpowiedzi na takie parametry wejĈciowe jak adresy
URL czy dane przekazywane w trybie POST.

Z perspektywy przeciötnego uĔytkownika aplikacja internetowa moĔe siö niczym nie róĔniè
od witryny internetowej. Nawet analizujñc kod wyĈwietlanych stron internetowych trudno
stwierdziè, czy byäy one generowane w sposób dynamiczny na podstawie danych skäadowanych
np. w bazie danych, czy miaäy postaè statycznych dokumentów HTML-a. Pewnñ wskazówkñ
moĔe byè rozszerzenie pliku, co wcale nie oznacza, Ĕe nie moĔna tego rozszerzenia sfaäszowaè
(w jednñ lub drugñ stronö). Aplikacja internetowa ujawnia swój prawdziwy charakter tylko
tym uĔytkownikom, którzy modyfikujñ jej dane. Z reguäy (choè nie zawsze) do takiej edycji
wykorzystuje siö interfejs HTML, ale równie dobrze moĔna sobie wyobraziè autonomicznñ
aplikacjö zaprojektowanñ z myĈlñ o bezpoĈredniej lub zdalnej edycji tych danych.

Wraz z wprowadzeniem technologii AJAX (od ang. Asynchronous JavaScript and XML), znanej
wczeĈniej jako zdalne wykonywanie skryptów (ang. remote scripting), znacznie rozbudowano
model interakcji z aplikacjami internetowymi. W przeszäoĈci interakcja uĔytkowników z aplika-
cjami internetowymi odbywaäa siö wyäñcznie za poĈrednictwem stron internetowych. UĔyt-
kownik Ĕñda od serwera zwrócenia strony internetowej, wprowadza i wysyäa zmiany za poĈred-
nictwem Ĕñdania POST protokoäu HTTP i otrzymuje w odpowiedzi nowñ stronö potwierdzajñcñ
dokonanie zmian lub prezentujñcñ zmodyfikowane dane. Model AJAX umoĔliwia nam wysyäanie
modyfikacji danych w tle (bez koniecznoĈci ponownego wyĈwietlania strony w przeglñdarce
uĔytkownika), co zbliĔa aplikacje internetowe do modelu interakcji znanego z aplikacji auto-
nomicznych.

Charakter aplikacji internetowych zmienia siö doĈè powoli. Nie moĔna oczywiĈcie ignorowaè
daleko idñcych róĔnic, które dzielñ wspóäczesne aplikacje internetowe od aplikacji implemento-
wanych jeszcze kilka lat temu, jednak rozwoju tego rodzaju aplikacji w Ĕadnym razie nie sposób
uznaè za zakoþczony. Projekty Gmail firmy Google i Office Live firmy Microsoft pokazujñ, Ĕe
rynek aplikacji internetowych ewoluuje w kierunku produktów dostarczanych za poĈrednictwem
internetu, które äñczñ w sobie najlepsze cechy rozwiñzaþ autonomicznych i internetowych.
O ile tradycyjne aplikacje biurowe oferujñ bogate moĔliwoĈci w zakresie interakcji i duĔñ
efektywnoĈè (w szczególnoĈci krótkie czasy odpowiedzi), o tyle aplikacje internetowe mogñ
zapewniaè swoim uĔytkownikom bezproblemowe i niezauwaĔalne aktualizacje, naprawdö
przenoĈne dane i mniejsze wymagania sprzötowe po stronie klienta. NiezaleĔnie od stosowanego
modelu interakcji z uĔytkownikiem, jeden aspekt pozostaje niezmienny — aplikacje internetowe
sñ systemami, których dostöp do podstawowych danych uzyskujemy za poĈrednictwem stron
internetowych (z reguäy strony internetowe umoĔliwiajñ takĔe modyfikowanie tych danych),
a pozostaäe interfejsy majñ raczej charakter uzupeäniajñcy.

Jak budujemy aplikacje internetowe?

Budowa aplikacji internetowej wymaga przygotowania co najmniej dwóch gäównych kompo-
nentów: platformy sprzötowej i platformy programowej. W przypadku maäych, prostych
aplikacji platforma sprzötowa moĔe siö skäadaè z pojedynczego serwera, na którym dziaäa

Czym jest architektura?

_

17

serwer WWW i system zarzñdzania bazñ danych. W tak maäej skali platformy sprzötowej nie naleĔy
traktowaè jak istotnego komponentu naszej aplikacji, jednak wraz z rozbudowñ oprogramowania
rola tego elementu w caäym projekcie zyskuje coraz wiöksze znaczenie. W tej ksiñĔce po-

Ĉwiöcimy wiele miejsca obu aspektom projektowania i implementowania aplikacji internetowych,
wpäywowi dziaäaþ podejmowanych w jednym aspekcie na drugi aspekt oraz technikom wiñzania
obu rozwiñzaþ (sprzötowych i programowych) celem tworzenia moĔliwie efektywnych architektur.

ProgramiĈci, którzy do tej pory mieli do czynienia wyäñcznie z aplikacjami internetowymi
maäej skali, mogñ siö zastanawiaè, po co w ogóle zawracaè sobie gäowö projektem platformy,
skoro moĔna z powodzeniem stosowaè gotowe rozwiñzania. W przypadku niewielkich aplikacji
takie podejĈcie rzeczywiĈcie zdaje egzamin. Oszczödzamy czas i pieniñdze, by ostatecznie
otrzymaè dziaäajñcñ aplikacjö, które caäkowicie speänia nasze oczekiwania. Problem pojawia
siö dopiero w aplikacjach wiökszej skali — gotowe rozwiñzania umoĔliwiajñce budowö takich
aplikacji jak Amazon.com czy Friendster.com po prostu nie istniejñ. ChociaĔ implementacja
zbliĔonej funkcjonalnoĈci wcale nie musi byè trudna, zagwarantowanie wäaĈciwego funkcjono-
wania tego rodzaju oprogramowania w Ĉrodowisku obejmujñcym miliony produktów i miliony
uĔytkowników bez zapewnienia odpowiedniej platformy sprzötowej wymagaäoby daleko
idñcego dostosowania i optymalizacji naszych rozwiñzaþ do konkretnych potrzeb. Okazuje siö,

Ĕe wszystkie najwiöksze aplikacje funkcjonujñce obecnie w internecie sñ „szyte na miarö”
z jednego istotnego powodu — Ĕadne inne podejĈcie nie gwarantowaäoby odpowiedniej skalo-
walnoĈci w warunkach ograniczonych moĔliwoĈci budĔetowych.

WspominaliĈmy juĔ, Ĕe rdzeniem kaĔdej aplikacji internetowej jest jakiĈ zbiór danych, które sñ
udostöpniane uĔytkownikowi i które z reguäy mogñ byè przez tego uĔytkownika modyfikowane.
Projektujñc czöĈè oprogramowania naszej aplikacji musimy zdecydowaè o sposobie skäadowania
tych danych (o schemacie ich reprezentacji np. w bazie danych), o sposobie uzyskiwania dostöpu
i modyfikowania danych (implementowanym przez logikö biznesowñ) oraz o sposobie ich
prezentowania uĔytkownikom (implementowanym przez logikö interakcji). Wszystkie te
komponenty omówimy w rozdziale 2., gdzie przeanalizujemy wystöpujñce pomiödzy nimi
zaleĔnoĈci oraz dalsze elementy, które skäadajñ siö na kaĔdy z tych trzech komponentów. Dobry
projekt aplikacji zawsze schodzi w dóä od najwyĔszego, najbardziej ogólnego poziomu do
konkretnych definicji architektury oprogramowania i sprzötu, komponentów skäadajñcych siö
na naszñ platformö oraz funkcjonalnoĈci implementowanej w poszczególnych warstwach.

Niniejsza ksiñĔka w zaäoĔeniu ma byè praktycznym przewodnikiem po projektowaniu i konstru-
owaniu aplikacji wielkiej skali. Po lekturze tej publikacji Czytelnik powinien wiedzieè, jak
naleĔy projektowaè aplikacjö i jej architekturö, jak naleĔy skalowaè gotowe systemy i jak powinny
przebiegaè procesy implementowania i wdraĔania w Ĕycie tych projektów.

Czym jest architektura?

Temat architektur aplikacji jest bardzo modny, co nie znaczy, Ĕe wszyscy, którzy posäugujñ siö
tym terminem, wiedzñ, co on oznacza. Kiedy architekt projektuje dom, jego zadanie jest doĈè
precyzyjnie okreĈlone: musi zebraè wymagania, przeanalizowaè róĔne opcje i sporzñdziè stosowny
szkic. Kiedy ekipa budowlana zapozna siö z planami architekta, bödzie oczekiwaäa kilku prostych
rzeczy: dom musi przetrwaè wichury, zapewniaè ochronö przed deszczem i zimnem oraz
oferowaè swoim mieszkaþcom wäaĈciwe oĈwietlenie. Na tym powinniĈmy zakoþczyè nasze
rozwaĔania poĈwiöcone budowie domów, poniewaĔ podobieþstwa pomiödzy tymi architektu-
rami sñ tylko iluzoryczne.

Czytaj dalej...

18

_

Rozdzia

ĥ 1. Wprowadzenie

Po pierwsze, gdyby budynek byä jak oprogramowanie, architekt musiaäby siö angaĔowaè w caäy
proces jego budowy, od wylania fundamentów po zaäoĔenie instalacji elektrycznych i sanitarnych.
Kiedy projektowanie i budowa domu dobiegnie koþca, architekt musiaäby przystñpiè do
wykaþczania i urzñdzania kilku pomieszczeþ w oczekiwaniu na przybycie czöĈci przyszäych
mieszkaþców, którzy zamieszkaliby w nowym domu przed jego ostatecznym wykoþczeniem.
BezpoĈrednio przed zakoþczeniem budowy do budynku wprowadziäoby siö mnóstwo innych
osób, które na wäasnej skórze sprawdzaäyby, jak zastosowane rozwiñzania sprawdzajñ siö
w praktyce. Nowi mieszkaþcy stawialiby jednak dodatkowe wymagania — chcieliby mieè do
dyspozycji wiökszñ liczbö sypialni, basen, piwnicö itd. Architekt musiaäby niezwäocznie przystñpiè
do projektowania nowych pomieszczeþ i atrakcji, modyfikujñc swój oryginalny projekt. W czasie
realizacji nowych inwestycji wszyscy dotychczasowi mieszkaþcy pozostawaliby jednak w prze-
budowywanym domu. Ciñgle korzystaliby z istniejñcych udogodnieþ, narzekajñc na haäas i pyä
powodowane przez prace ekip budowlanych. Co wiöcej, wbrew wszelkiej logice do wciñĔ
rozbudowywanego budynku wprowadzaliby siö kolejni mieszkaþcy. Po zakoþczeniu wprowa-
dzania modyfikacji nowo przybyli mieszkaþcy natychmiast zaczöliby zgäaszaè nastöpne wnioski
o rozbudowö domu o kolejne pomieszczenia i dodawanie dalszych atrakcji.

Kluczowñ cechñ dobrego architekta aplikacji jest zdolnoĈè przewidywania tego rodzaju proble-
mów od samego poczñtku. Gdyby architekt naszego hipotetycznego domu rozpoczñä od budowy
wielkiego gmachu z bardzo skomplikowanymi instalacjami, w Ĕaden sposób nie mógäby
sprostaè dalszym Ĕñdaniom. W chwilö po zakoþczeniu budowy mieszkaþcy wyprowadziliby
siö w inne miejsce, gdzie mogliby uczestniczyè w przebudowie zamieszkiwanego domu zgodnie
ze swoimi potrzebami. Z utratñ mieszkaþców musielibyĈmy siö liczyè takĔe wtedy, gdyby
rozbudowa naszego domu zajmowaäa zbyt wiele czasu. Musimy wiedzieè, jak rozpoczñè prace
we wäaĈciwej skali, by w przyszäoĈci moĔna byäo w miarö bezproblemowo ten dom rozbu-
dowywaè.

Z powyĔszych rozwaĔaþ w Ĕadnym razie nie wynika, Ĕe architekt musi od samego poczñtku
nie popeäniaè Ĕadnych bäödów w przyjmowanych zaäoĔeniach. Skalowanie typowej aplikacji
polega miödzy innymi na analizie i dostosowywaniu wszelkich aspektów pod kñtem ich
ewentualnego dopasowania do nowych wymagaþ. Nie ma w tym nic zäego — zadaniem archi-
tekta aplikacji jest tylko minimalizowanie czasu potrzebnego do modyfikowania poszczególnych
komponentów oraz moĔliwie precyzyjne przygotowywanie projektu poczñtkowego i projektów
niezbödnych zmian.

Od czego nale

ży zaczéë?

Aby przystñpiè do projektowania i budowy pierwszej aplikacji internetowej wielkiej skali,
musimy dysponowaè czterema niezbödnymi elementami. Po pierwsze, bödziemy potrzebowali
koncepcji. Z reguäy jest to element najtrudniejszy, poniewaĔ nie ma wiele wspólnego z trady-
cyjnymi dziaäaniami, do których przywykäa wiökszoĈè inĔynierów. Techniki i technologie
prezentowane w tej ksiñĔce moĔna co prawda stosowaè podczas realizacji maäych projektów,
jednakĔe w przypadku wiökszych projektów wymagajñcych zaangaĔowania wielu programistów
ich wykorzystywanie ma charakter opcjonalny. JeĈli dysponujemy aplikacjñ, która nie zostaäa
jeszcze wdroĔona w docelowym Ĉrodowisku lub jest stosunkowo maäa i wymaga skalowania,
moĔemy przyjñè, Ĕe najtrudniejsze za nami — wówczas moĔemy od razu przystñpiè do projek-
towania rozwiñzaþ w wiökszej skali. JeĈli dysponujemy aplikacjñ wielkiej skali, warto przestu-
diowaè tö ksiñĔkö, by przekonaè siö, czy do tej pory postöpowaliĈmy wäaĈciwie, i przygotowaè
siö do dalszego rozwoju naszego produktu.