O Fakturoidu z pohledu technologií

Tentokrát článek techničtějšího rázu, který vznikl jako rozhovor. Otázky pokládá Tomáš Jukin (T), jeden z našich ochotných betatesterů. Odpovídá Lukáš (L).

T: Zajímalo by mě proč jste pro Fakturoid zvolili zrovna Ruby on Rails? Co bylo hlavním argumentem?

L: O tom, že jsme použijeme Ruby on Rails, bylo rozhodnuto vlastně předem :). Honza mi tweetnul před více než rokem, jestli nechci v Rails pomoci zrealizovat jeho nápad na aplikaci. Protože to znělo zajímavě, setkali jsme se v Praze a po dobrém obědě a mnoha hodinách povídání jsme položili základy další spolupráce. Uplynul půlrok práce na projektu, který skončil zatím v šuplíku a začal vznikat Fakturoid.

Rails jsou z pohledu programátora i designéra velmi elegantní vyjadřovací prostředek pro tvorbu aplikací. V současné době existuje již velmi snadná podpora pro deployment, mnoho dokumentace, integrace, pluginů a externích knihoven. Naopak by se mi těžko hledali argumenty pro použití jiné technologie. Rails 3.0 zcela očekávatelně posunou laťku ještě výš, nemůžeme se dočkat.

T: Kterou databázi Fakturoid vlastně používá? Postgres? Co je podle tvého její výhoda oproti MySQL? Také vím, že jste uvažovali nad MongoDB, proč jste se ji nakonec rozhodli nepoužít?

L: Ano, používáme PostgreSQL. Určitě by šla použít třeba i MySQL, ale delší dobu preferuji PostgreSQL. Dobře se mi s ní pracuje po stránce managementu, zatím má ale složitější konfiguraci replikace, kterou plánujeme v pozdějších fázích používat jako online zálohu. MongoDB se mi moc líbí, ale Fakturoid začal vznikat ještě před tím, než pro MongoDB byla dostupná rozumná „OM” knihovna. Tou tehdy chybějící knihovnou je vznikající MongoMapper. Navíc SQL stále není pro některé úlohy k zahození, třeba Server Density přešla na MongoDB, ale jejich billing zůstal na MySQL.

T: Kolik Fakturoid využívá databázových tabulek, kolik má relačních vazeb a kolik dotazů do databáze provádí při průměrném požadavku? Zajímalo by mne totiž, jaká je asi datová složitost takovéto aplikace…

L: Máme hodně jednoduchý databázový model, který tvoří pár tabulek (faktury, opakující se faktury, řádky faktur, kontakty, uživatelé). Podobně jako jiné railsové aplikace, ukládáme data všech zákazníků do jedné databáze. Pro rozlišení zákazníků používáme doménu 3. řádu. Průměrný počet dotazů se dost liší akce od akce, právě jsem uprostřed optimalizací, až to dopadne, dám vědět.

T: Z blogu a i ze schopností Fakturoidu usuzuji, že kladete velký důraz na jeho API. Je podle tebe schopnost interakce webových aplikací s jejich okolím důležitým faktorem, či dokonce nutnou podmínkou pro jejich úspěšnost? Proč?

L: Mnoho aplikací může fungovat bez API. Pohříchu třeba české banky. Ale není to ono. Například Twitter obslouží mnohem víc API požadavků než webových. Nebo nová inovativní využití RSS (třeba odebírání feedu uživatelských akcí ve web aplikaci). Okolo aplikací 37signals vznikl zajímavý ekosystém, ve kterém umí spolupracovat aplikace třetích stran (včetně desktopových a mobilních). Zvedá to hodnotu takových služeb. Umožňuje to propojovat. Za pozornost stojí iniciativa kolem webhooks (na základě akce služba udělá POST požadavek), které jsou pěkně využity na GitHubu pro oznamování nových commitů. Nebo Tinder API pro Campfire.

T: Jaká všechna API do budoucna plánujete? A s jakými službami už je Fakturoid propojen a jaké by ještě měly přibýt?

L: Zatím umíme importovat kontakty podle IČ z databáze Ministerstva financí. Pro události nabízíme RSS. Přes naše REST API půjde vystavit a odeslat fakturu, založit nový kontakt nebo označit fakturu za zaplacenou. API plánujeme využívat i interně, kdy přes něj budeme vystavovat faktury pro zákazníky Fakturoidu.

T: Má vnitřní architektura Fakturoidu nějaká zásadní omezení?

L: Z technického hlediska by skoro nic podstatného nemělo být problémem a také není. Je tu jedno veliké ale – rádi říkáme „Ne”. Jsou to rozhodnutí o tom, jak se bude naše aplikace používat, které funkce jsou nezbytné, a které již nikoliv. Tomu je podřízen celý vývoj a návrh. Inspirací k tomuto přístupu je kniha Getting Real a vlastní životní zkušenost.

Z funkcí, kterým jsme řekli „Ne”, vybírám: vedení výdajů, jiný jazyk než čeština, plnohodnotné účetnictví, více vzhledů faktur… Počítáme s tím, že některé z těchto věcí se časem změní, ale zatím musely dostat červenou.

T: Jak řešíte nasazování aplikace na web? Používáte nějaké automatizované nástroje, nebo zůstáváte u FTP?

L: Používáme Capistrano. Capistrano je v ruby napsaný nástroj pro spouštění příkazů na vzdálených serverech. Primární použití je pro nahrávání nových verzí webových aplikací z repository. Pomáhá s každodenní prací a téměř eliminuje nutnost se SSHčkovat na server. Proces nasazení nové verze pak spočívá v pushnutí změn do git repository a spuštění cap deploy. V našem případě dojde k restartu serveru, spuštění databázových migrací, updatování cron tasků a přesměrování symlinků. Pomocí dalších tasků lze snadno přegenerovat konfiguraci virtual hostu, zjistit volné místo na disku nebo stáhnout produkční databázi na lokální stroj pro experimenty.

Ač Capistrano používají převážně rubysté, tak ho s úspěchem nasazuji i na weby v PHP. Pokud tedy stále někdo používá FTP pro něco složitější než pěti-souborový web, tak doporučuji přesun k něčemu praktičtějšímu :)

T: Jakými prostředky chráníte data uživatelů? Předpokládám že Fakturoid zcela jistě disponuje ochranou proti XSS, SQL injection a UTF-8 útokem skrze formuláře? Jakými postupy a prostředky jste tohoto dosáhli? A která data šifrujete a ukládáte pouze zašifrovaná?

L: Nebudu popírat, že zabezpečit webovou aplikaci, je složitý problém. Nejlepší obrana je útok. Jako moc dobré základní vodítko již nějakou dobu používám tuto příručku, obsahuje hezké shrnutí útoků a návodů, jak se k nim v Rails postavit. Do spuštění veřejného ostrého provozu bude veškerá komunikace mezi uživateli a našimi servery šifrována pomocí SSL a to i pro free účty.

T: Jakými prostředky chráníte své uživatele před ztrátou jejich dat?

L: Zálohujeme – často a na více míst. Dokud je naše databáze malá, tak si můžeme dovolit velmi časté zálohy. Až bude větší, tak se vrhneme do online replikace. Do Fakturoidu lze nahrávat i obrázky pro kontakty, jsou to malinká PNGčka, která se velmi dobře zálohují. Nabízíme také XML exporty všech informací, které u nás uživatel má, takže každý může zálohovat i nezávisle na nás.

T: Kdy plánujete Fakturoid nasadit v ostrém provozu? Jsou ještě nějaké killer features, které do té doby teprve plánujete implementovat?

L: Brzy. Určitě, sledujte robota na Twitteru, občas se tam prokecne. S rozsahem funkcí jsme již poměrně spokojeni, teď leštíme jejich provedení. Posledním větším soustem jsou opravdu pěkné PDF faktury a zdá se, že již máme ten správný recept.

T: Už se na to těším! No, to je zatím asi vše. Děkuji za rozhovor a držím palce v dalším vývoji. Ať to jde hezky od ruky!

L: Díky za otázky! Ahoj.