Konstrukcija baze

Pravim konstrukciju baze za jedan projekat koji će biti API za razne firme. Tako db server treba da ima sledeće baze:

Main
Firma 1
Firma 2
Firma 3
...

Podaci u ovim firma bazama neće biti nešto nebesko veliki jer su to uglavnom manje firme ali ova Main baza me brine. Tu će biti zajednički podaci kao što su firme, korisnici, prava pristupa, podešavanja i ostalo. Tako recimo kad stigne neki Rest zahtev, prvo se kontaktira Main baza da se proveri authentikacija i authorizacija pa ako to zadovolji, dalje se radi glavni zahtev nad podacima korisnika. To znači da će svi zahtevi ići preko te Main baze i logično da će biti najviše opterećena.

Sa te tačke gledišta, da li da u samom startu predvidim da ta baza bude na posebnom serveru ili to neće doneti nikakve dodatne performanse?

Naravno, za početak će sve da se vrti na istom serveru: Apache(php) i MySQL, kasnije mislim da odvojim Apache od db servera ali sad imam dilemu da li i da odvajam dodano baze pa da imam sledeće servere: Apache - MySQL (Main baza) - MySQL (baze firmi).

Ovo pitam da bi od početka napravio što bolju postavku da kasnije imam manje glavobolje kad krene veći load.

nije bas jasno sta je jedinstveno a sta je zasebno za firme ali
generalno ako mozes da isprojektujes tako da je svaka baza na posebnom
serveru isprojektuj tako, pa ih za pocetak sve stavi na isti ali bitno
je da mozes da ih izvuces na zaseban kada za to dodje potreba

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Na primer, stigne mi Rest zahtev: ja sam Pera Perić, firma Šverc Komerc doo, daj mi spisak mojih faktura.

Prvi korak je da proverim bazu korisnika, tj. da vidim da li postoji Pera, da li je poslao ispravnu lozinku, onda da vidim da li postoji firma Šverc Komerc doo i da li Pera ima pristup toj firmi. To sve radim na osnovu te zajedničke baze gde stoje svi korisnici, spisak firmi, prava pristupa i slično...

Kad utvrdim da je sve ok, onda kontaktiram bazu gde stoje podaci od tog korisnika. Dakle svaka firma je posebna baza. Vratim spisak faktura ili šta je već korisnik tražio.

to moze se odradi na mnogo nacina ali ako ja dobro razumem nikada se
podaci firme X i firme Y ne mesaju, jedini "zajednicki" podaci koji
postoje su aplikacijski podaci koji su ono "lista firmi, i user data"? u
tom slucaju ja bi napravio da svaka baza bude na svom serveru (naravno u
startu sve stavis na isti server ali se i dalje ponasas kao da su svaka
na svom pa posle po potrebi razdvajas) i imas jednu bazu koja je appdb u
kojoj imas usere i njihov access na razne firme i imas listu firmi gde
za svaku firmu imas datu gde je database server na kom se nalazi baza
... a sve baze od firmi su ti 100% identicne po strukturi (znaci
razlikuje se samo dbname)

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Da, tako sam i mislio samo što bi bilo previše da svaka firma ima poseban server, više sam mislio da sve firme stavim pod jedan db server. Ne znam kako se MySQL ponaša kad u okviru jednog servera ima stotine ili hiljade manjih (a identičnih po strukturi) baza.

I kad sam već ovde. Jel ima neki jednostavan način da sinhronizujem strukturu velikog broja baza? Recimo, ako u procesu razvoja nešto promenim na jednoj bazi, da i ostale mogu da se sinhronizuju ili moram da skriptujem svaku promenu pa posle pustim na ostalima?

ja ti opet kazem, dizajniras da moze svaka firma na poseban server, a ti
onda stavis za pocetak sve na jedan server pa sutra na 1000 firmi
skontas da ti je optereceno pa uzmes drugi server i prebacis 500 na
njega pa imas 2x500, pa prekosutra treci pa imas 3x330, pa ti dodje jos
1000 pa uzmes 4 servera po 250 etc etc ... kapiras ... znaci dizajn sw-a
i baze je takav da je svaka baza na svom serveru i imas u appdb bazi na
kom ti se serveru nalazi baza za firmuX i kako se zove baza za firmuX
nesto tipa

company_id, ipaddr, dbname, dbuser, dbkey


i onda nema veze sto ce za prvo vreme svi rekordi u toj tabeli da imaju
isti ipaddr... imace razlicido dbname ... a sutra kad migriras neke baze
na drugi server promenice se i ipaddr .. kapiras ..


sto se mysql-a tice broj baza ne pravi neku razliku dal ce imas 2 ili
2000 baza nema mnogo razlike... cak je za neke stvari zgodno kada imas
vise baza (na primer za paralelnu replikaciju :D )

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Dizajn je dobar, ali prosto savet: Ako vec imas externi REST API, i ako ces da autorizujes korisnike ka tom API-ju, probaj da ti autorizacija bude OAuth. :)

Taman ces imati dobru ideju kako da napravis tu "Main" bazu, za OAuth mislim da imas gotovih primera zilion.

Potpis

Please do not feed the Trolls!

Blasphemy? How can I blaspheme? I'm a god!'

OAuth je više za varijantu kad imaš Api pa da klijenti mogu brzo i lako da se priključe. Ovde nema takvog slučaja, web i mobile klijent će biti moj a eksterni korisnici će se dodavati samo ako to korisnik eksplicitno odobri. Dakle biće običan token koji će se porediti sa onim iz baze. Tako da ne moram da se bavim OAuth-om, na svu sreću, jer sam ga probao i žešće mi je komplikovan.

A JWT? Standard je isto... Podrazumeva da obe strane imaju trusted metod da razmene neki secret, ali ako su klijenti tvoji, onda mozes.

Cisto probam da ti dam savet da izbegnes "pametna" resenja - i da ides na standard. :D

Potpis

Please do not feed the Trolls!

Blasphemy? How can I blaspheme? I'm a god!'

Ovako... ideja da pravim tu aplikaciju postoji već duže ali nikako da se nakanem. Konačno sam počeo sa time i napravio sam neki kostur i malo da izađem iz gužve i ozbiljno se bacam na to. Problem je što sve radim sam i u slobodno vreme. A kad sam radiš, onda ispred tebe postoji gomila nekih stepenica koje moraš da pređeš. Tako sam morao da se bavim i tehničkim aspektima, tj. koji server side da odaberem, kako cliente da osmislim, kako sigurnost, gde i kako hostovati, kako organizovati bazu... i pored svih tih tehničkih stvari, bitan momenat je i sam biznis model, koje funkcionalnosti aplikacija treba da ima, kako će se to komercijalizovati i koješta drugo. Tako da već mesecima unazad pripremam kostur sa svim tim stvarima i uviđam koliko je teško doći do softverskog proizvoda kad radiš sam jer moraš da se baviš svim stvarima, od ideje, zatim biznis modela, tehničke realizacije i na kraju komercijalizacije. Tako sam i jedan segment vremena odvojio za security pa sam proučavao tehnologije u vezi toga. Klijent za REST api će biti web aplikacija, tj. brauzer. Prvo desktop a kasnije i mobilna web aplikacija, najverovatnije PWA. OAuth sam od početka otpisao jer mi je bio previše komplikovan i nije mi potreban jer neće biti takav tip aplikacije. JWA podrazumeva trpanje nekakvih enkriptovanih podataka u token ali u tom slučaju treba da imaš sertifikate i zezancije a to nije jednostavno ako ti je client web brauzer. Ajde kad bih pravio mobilnu aplikaciju, onda bi i moglo. Na kraju sam se odlučio za prost seljački token. Kad se registruješ i posle prvog logovanja, u brauzer se snima token i svaki dalji api poziv ide sa tim tokenom. Token je u bazi, il ga ima il ga nema. I to je to. Tako da krećem od tog modela bezbednosti a kasnije, ako se priča dovoljno raširi, nije problem da se stvari menjaju. Problem je što ne želim u samom startu da previše odem u širinu i pokušam da shvatim smisao univerzuma pre nego što sam i počeo. Jer kad tako kreneš previše široko, ništa ne uradiš. Zato gledam da mi sve bude jednostavno a dovoljno sigurno, pa jednog dana, ako bude trebalo, uvek mogu da se organizuju profesionalci za te neke određene segmente. Sad sam malo otišao naširoko sa pričom, ima Bogdan da nas likvidira što mu pravimo šum u temi ali evo nećemo više...

nije bogdan moderator na temi tako da... ima ko treba o tome da brine ..
sad ono nema veze sa mysql-om ali na zalost ne znam za neki deo foruma
gde bi o takvoj postavci sistema mogao uopste da pricas, ono kada sam
kukao neki dan je bilo direktno vezano za "kako u php-u xyz" a php tema
postoji, ovo realno nema gde da se smesti na forum jer topic kao takav
ne postoji..

ja cu samo da ti kazem da razmisljas na pogresan nacin :( vzv toga sto
si sad pisao oko logovanja i security-a

ako mislis da ikad komercijalizujes to

1. mora imas te kljuceve

2. mora bude mnogo toga izenkriptovano

ako mislis da ikad uvatis veceg klijenta ili mozda prodas taj proizvod
ili zatrazis neki sertifikat da bi mogao da ides na neki tender

1. mora imas te kljuceve

2. mora bude sve izenkriptovano

3. mora sve da bude po priznatim standardima - posebno trivijaliteti
tipa login

ako hoces to ozbiljno da radis na 1+2+3 mora dodas i modularnost i
slojevitost

dalje, nemoj pogresno da me skontas i nemoj da mislis da zelim da te
uvredim ili da sebe nesto uzdignem, nemam potrebu ni za jednim ni za
drugim ... ovo su ti fakta a ti ih prihvati kako zelis

1. ako ti je oauth "previse komplikovan" naje123 si sa tom aplikacijom
jer ako ti je resen, odlicno dokumentovan, i relativno jednostavan,
sistem za logovanje "previse" i ne mislis da treba da ulozis vreme i
trud da to savladas, sanse da ces zavrsiti tu aplikaciju su tu negde u
rangu sa tim da ja uspem da skinem 70kg za narednih 2-3 meseca

2. recenica "JWA podrazumeva trpanje nekakvih enkriptovanih podataka u
token ali u tom slučaju treba da imaš sertifikate i zezancije a to nije
jednostavno ako ti je client web brauzer." je "strasna" slicno kao ovo
pod 1 ali mozda cak i strasnija? ti si izgleda zamislio da ces na
finansiskoj aplikaciji jedini security imati default browserov https i
to je dovoljno? uz to ces lokalno na browseru da cuvas token koji ce
generises na user/pass i poredis ... to je ok za ono tarot karte, ili
one aplikacije sto crtaju noseve na real time snimak... to nikako nije
za projekat koji ce da ima "API za razne firme", "i na kraju
komercijalizacije" etc..

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Dosta sam proučavao REST security i stvar uopšte nije tako prosta i ne postoji idealno rešenje. Najsigurnija varijanta je svakako korišćenje sertifikata ali to u mom slučaju otpada jer je klijent web aplikacija u brauzeru. Što znači, ako bih hteo da se koriste sertifikati, onda bi morao da cimam sve korisnike da instaliraju public key u brauzer a to je malo previše za sajt koji pretenduje da bude public. Dakle ta vrsta tehnologije se ne koristi u public webu i treba se orjentisati na druge stvari. Zato su smišljeni tokeni (što je u suštini zamena za par username/password) sa kojima se klijent predstavlja. I svi tokeni rade po istom principu, posle logovanja ih dobiješ, stoje kod tebe u brauzeru (gde drugo) i koriste se za svaki sledeći api poziv. Ako neko želi da te hakuje, to može da uradi na dva načina: 1. da presretne komunikaciju i mazne ti token i kasnije se predstavlja kao ti, 2. da ti mazne token iz brauzera (neka skripta, lično prisustvo...) pa opet da se dalje predstavlja kao ti. Ovo prvo se rešava korišćenjem HTTPS-a a za ovo drugo moraš da paziš kakve skripte puštaš na sajt. Dakle, nebitno koju vrstu token standarda koristiš (OAuth, JWT, kojigod...), taj token mora da stoji negde i ako haker ima pristup toj lokaciji, može da ga mazne. REST server nikako ne može da zna ko je klijent već samo može da verifikuje podatak koji dobije. Dakle ako se javi Pera i kaže da je on Pera i pokaže svoj token, REST nema načina da zna da li je on zaista Pera ili je neko Peri maznuo token i predstavlja se kao on. Tako da je sa te tačke gledišta potpuno nebitno da li se koristi OAuth, JWT ili nešto treće. Sve te tehnologije imaju neke svoje prednosti ali u nekom drugom spektru. OAuth ti daje mogućnost da jednostavno registruješ eksterne klijente (što meni nije potrebno by_design) a JWT ima prednosti ako se koristi enkripcija putem sertifikata. Tako se vraćamo na to da je običan seljački token potpuno istovetno bezbedan (ako se kvalitetno implementira) kao i gorepomenute tehnologije jer su one zapravo samo varijacija na temu. Naravno, postoje tu i druge stvari koje mogu da pomognu: određeno vreme trajanja tokena, 2-step verifikacija, praćenje IP adrese itd... ali sve to ne menja osnovnu poentu. I kao što rekoh, security koji planiram da implementiram svakako nije bezvezan nego je iznad proseka. Nije nebeski ali i ne treba da bude a može i to jednog dana. Prosto tako funkcioniše web. Ima tu nekih inicijativa za napretkom tehnologije, ja sve pratim i sigurno neću zaostajati.

Ti bas neces da razumes, a Bogdan se ubi da ti objasni:

Gledaj: Ti implementiras neki svoj algoritam. Sve da si u pravu (a iskreno, sve pises kao jedan pasus, meni je naporno da citam - a i tvoj opis nije isto sto i implementacija), ti si napisao SVOJ standard. Bilo ko ko bude hteo da implementira to, kao neki 3rd party, morace da to radi od nule. Bilo ko ko bude hteo da to proveri morace da radi analizu. Bilo koja sertfikacija ti nece proci jer nisi po standardu.

Sve i da je tvoja implementacija savrsena - nije standard.

Dodatno, implementacija OAuth-a za klijent (npr. Web App koji je HTML5 / JS i trci u browseru) je extremno prosta: Ubaci se gotova biblioteka i samo se pozove. Opet, referentna implementacija. Mobilni app? Ista prica. Nesto trece? Nikakav problem. Ovako, da bi se bilo ko nakacio mora da od nule implementira tvoj "standard". Prilicno sam siguran da postoji i OAuth biblioteka za bilo koji server side koji zelis da koristis, pa mozes i tu da koristis to - a ne da pises od nule. Isto i za JWT.

Konacno, OAuth ima dva tokena: Jedan za App, drugi za user-a. Da, ako neko korisniku ukrade racunar na kome je snimljem token on moze da se predstavi kao on - ali to nije poenta. Ako se user izloguje sa drugog racunara i ponovo uloguje dobice nov token - i stari vise ne vazi. Da, mozes i ti to da implementiras, ali opet - tvoja implementacija nije standard.

Potpis

Please do not feed the Trolls!

Blasphemy? How can I blaspheme? I'm a god!'

Mala ispravka. Ne pišem nikakav standard, ovo što ja koristim je HTTP Basic Authentication i Bearer Token. To sve već postoji i imaš "standard" za to. OAuth i JWT su samo varijacija toga, ništa više. Ne donose nikakvu dodatnu bezbednost za ovo što meni treba.

Eksterno kačenje na Api nije predviđeno osim u specifičnim situacijama. Odeš u podešavanja, generišeš Api ključ, definišeš prava pristupa, rok važenja i šta sve treba i taj ključ daš klijentu. Za tog klijenta nema prostije od toga, dobije ključ i tera dalje. Upravo mi je poenta u tome da vlasnik podataka mora eksplicitno i ručno da generiše token i preda ga trećoj strani (jer to potvrđuje da zna šta radi) umesto da se koristi OAuth gde treća strana može da pristupi podacima običnom nepažnjom korisnika koji će samo da klikne na Allow.

Jedno od resenja za pricu s' pocetka bi moglo biti:

1. Main deo bude centralni deo ali u njemu samo cuvas tkz. smerni deo koji upucuje i utvrdjuje ko je u pitanju sto se tice klijenta/korisnika tj. firme u pitanju - namena samo za autonetikaciju i autorizaciju;

2. Dodati Client_Main ili vec kako si poceo Firma_Main - tu cuvas sve sto je vezan od pravila i svega sto je vazno za tu firmu. Znaci globalni MAIN nakon autorizacije i potvrde autentitcnosti prosledjuje na tacku 2. i odatle sve posle ide sta treba...;

Sutra mozes da razdvojis da ti recimo jedan server bude main deo i koji samo vrsi autentikaciju i autorizaciju i mozda tkz. federaciju ako je budes pravio izmedju korisnika tj. firmi;

Ostalo sve moze da bude na istom ili drugim serverima posto moze da se desi da po obimu neki klijent/klijenti tj. firma/firme bude/u preobimna/preobimni i da zahteva dodatne serverske resurse - ovim lako razdvajas celu tu pricu i ustvari pretvaras klijente/firme u nodove koje kontrolises pre svega preko main dela. Takodje u main delu mozes da za svakog korisnika po kreiranju njihovog naloga kreiras sertifikat te tako svaki klijent ima svoj digitalni sertifikat koji bi se dalje koristio za potpisivanje i kriptovanje sadrzaja ako je to potrebno.

Za ovo ne bi bilo lose isto da pogledas kako recimo f-ionise RIM BlackBerry Server i o istom malo pogledas o tome na netu

@S A J A, mislim da nisi razumeo nkrgovica (ili ja nisam ).
Preporuka za OAuth nije zbog logina (authentifikacije) nego zbog autorizacije. Njega bi koristio da odredis ko moze cemu da pristupa. Naravno, mozes i skroz bez njega, ali ako mislis da ce mozda jos neko trebati da implementira nesto da se prikljucuje tom sistemu, mogao bi da tu autorizaciju radis po postojecem standardu kako bi unapred olaksao. Slicno kao sto si i u startu rekao da hoces da unapred isplaniras to sa bazama kako bi izbegao kasnije muke.


_{Izvinjavam se sto izigravam drvenog advokata ali citam sa strane i vidim da se ne kapirate}

Potpis

Nebojsa Milanovic:
-Trumpa smatram vrhunskim predsednikom i voleo bih da živim u državi na čijem je on čelu
-Rusija ne laže, ne vodi osvajačke ratove
-Trump je svetla tačka u USA blatu
-Elon Musk, možda najpametniji i najtrezveniji Amerikanac

Takodje ne bi trebalo da se mesa dizajn i sturktura dbms i nacinini/tipovi autorizacije i autentikacije korisnika ka web serverisu...

elem na sve to evo da podestim malo o OAUTH

https://youtu.be/wA4kqKFua2Q

Shadowed, hvala na pojašnjenju. Jeste tu bilo malo gluvih telefona ali mi se čini da smo se sporazumeli da se ne slažemo ;)

Evo, da probam još jednom, iz drugog ugla. API koji pravim će 99% biti korišćen samo od strane web interfejsa koji isto ja pravim. To sam odvojio iz praktičnih razloga i brzine a ne da bi API bio otvoren prema svetu. Naravno, biće potrebe da korisnik želi da integriše podatke sa trećom stranom i onda mora da dozvoli pristup API-u. Ok, slažem se da ako želim da sve isplaniram unapred i da sve to deluje dovoljno ozbiljno, bi trebalo da koristim nešto što je standard. Međutim, za sada mi ne treba taj feature i imam prečih stvari za implementaciju. Recimo struktura baze mi je daleko važnija jer će to kasnije biti teže za promene a OAuth mogu da dodam kad bude trebalo, tako da ovde važi: "sve što možeš da ostaviš za kasnije, ostavi za kasnije". Ne, ozbiljno, ne znam da li ste nekada osmišljavali svoj proizvod ali tu ima žešće mnogo posla. Naravno da nemam para pa da platim programera, security officera, database officera, devopsa, istraživanje tržišta i koješta drugo već sve moram sam da radim. Ja sam pre svega biznis konsultant za ERP sisteme, znam šta želim da dobijem a sve ove tehničke stvari su mi, nažalost, samo nužno zlo.

To je skroz ok, na tebi je da povuces liniju izmedju toga koliko hoces da ides u sirinu. U potpunosti razumem tvoju situaciju. Ja sam se bar nagledao gomile koda koji postoji samo zbog overarchitecturing-a a nikad nije bilo potrebe za istim (citaj: bacene pare). S druge strane, vidjao sam i obrnute situacije gde je projekat toliko neprosiriv da je lakse praviti ga ispocetka. Zato i kazem, na tebi je da procenis gde ces biti izmedju te dve krajnosti (da li ces dobro proceniti je drugo pitanje, to ide sa iskustvom).

Btw, u cemu radis aplikativni deo?

Potpis

Nebojsa Milanovic:
-Trumpa smatram vrhunskim predsednikom i voleo bih da živim u državi na čijem je on čelu
-Rusija ne laže, ne vodi osvajačke ratove
-Trump je svetla tačka u USA blatu
-Elon Musk, možda najpametniji i najtrezveniji Amerikanac

Da, mora da se nađe sredina. Ako se previše ode u širinu, kraja nigde, što više radiš to ti ostaje više posla i padaš u bedak. Sa druge strane, ako napraviš realniji koncept, već kad krenu da stižu prvi rezultati, to te ohrabruje da nastaviš. Tako da sad gledam da "isprojektujem" osnovnu funkcionalnost ali tako da može da se nadograđuje. Imam 15 godina iskustva sa ERP rešenjima tako da poznajem funkcionalni i database model rešenja koje je mnogo iznad ovog mog pa u samom startu mogu da postavim stvari tako da dugoročno budu održive za razvoj. Da nemam to znanje, nema šanse da bih uspeo. Da se razumemo, čisto programersko znanje je đoka, sa tim se ne može napraviti ozbiljan proizvod.

Dakle, serverski deo je REST Api preko PHP-a i MySQL-a. Neko vreme sam se razmišljao da koristim NodeJS ali mi se nije svideo. Njegova asinhrona priroda na server strani mi nikako nije prijala plus što testovi performansi pokazuju da ne prednjači u odnosu na PHP. S obzirom da servis koji pravim će imati i free varijantu, u samom startu se spremam za veliki load pa dosta vremena gubim na mikrooptimizacije. Na jefitnom VPS-u koji sam zakupio (1 vCPU i 2GB rama) uspevam da vratim JSON sa 1200 rekorda (koji se na clientu čitavaju u datagrid) za 0.001 sekundu i 90 kb potrošene memorije. Bolje od toga nisam uspeo da izvučem. Preko sajta za testiranje REST Api-ja sam ga opteretio sa 250 poziva po sekundi, gde svaki api poziv ima 5 poziva ka bazi, što čitanje i upisivanje, i to mi jede 85% procesorske snage na ovom slabom VPS-u, od čega je oko 35% load mySQL servera. Memorija ne prelazi 500kb. Tako da, performansama sam za sada prilično zadovoljan. To sam postigao time što ne koristim nikakav frejmvork već samo čist PHP i gledam da svaki REST poziv nema apsolutno ništa što je višak za ono što treba da obavi.

Za client sam odabrao klasičnu HTML-CSS-JS kombinaciju. Kupio sam dve profi (i ne tako jeftine) Admin teme tako da ću odatle da poskidam sve šta mi treba i da punim JSON podacima koje mi stižu od Api-ja. Za sad mi je client deo na shared hostingu ali to jednog dana kad zaživi, prebaciću na VPS. Dakle client na jednom VPS-u a Api na drugom. Kasnije ću da odvojim mySQL od Apache-a, sve te faze sam ubacio u projekat ali to je već dalja budućnost. Na client strani takođe ne koristim nikakav frejmvork. Volim da se bavim detaljima i ne podnosim kad mi je projekat pun koječega što mi ne treba. Tako da sam sve sam pravio, klase za datagrid, rutiranje i drugo. Recimo, kad odeš na client aplikaciju, prvo ti se učita početna stranica i glavni meni a onda kad klikćeš na glavni meni, samo se u pozadini, preko AJAX-a povlače view-ovi, dakle kompletno po SPA standardu. Čak sam i otišao korak dalje, svaki view koji se skine sa servera (klikom na stavku menija), se snima u memoriju brauzera (array variablu) pa kad ponovo klikneš na tu stavku menija, čitam stranicu iz memorije. Tako posle kraćeg šetanja kroz aplikaciju, sve stranice budu u brauzeru, praktično se samo povlače JSON podaci. Tako sam dobio da sve radi munjevito brzo, praktično kao da koristiš desktop.

I tako, to je otprilike struktura, sad je fazi kostura ali za 2 meseca krećem da punim pravim stvarima, preko leta imam neke druge obaveze pa ne mogu da stignem.