Konstrukcija baze

Tako je @Shadowed. Vodi racuna da ti OAuth omogucava i fine varijante kao npr. "Koliko pojedinacni klijent moze da ima API requests u minutu/satu/danu". Deluje da ti nikad nece trebati dok ti jedan remote klijent ne fasuje neki mallware. ;)

@SAJA: Ako vec hoces samo bearer token, probaj da bude JWT. Jeste, ti si u pravu, ali zivot je laksi svima ostalima kad imaju gotovu biblioteku. Bice i tebi ako se potrudis da je nadjes. Konacno, ako ti ikad iko bude radio audit, imaces problem sa tvojim custom. Ako imas standard, nemas problem.

Takodje, ako imas free servis, sanse da ce neko da ti se nakaci i smara API su JAKO velike ;) Razmisli o rate limitingu po klijentu.

Nemoj da me shvatis pogresno, ja sam odusevljen da neko ko zna BIZNIS procese pravi ERP sistem. Tako i treba da bude i trudim se da ti budem podrska - ali mislim da si resio da izbacis sve sto smatras nebitnim sa biznis strane - i da ce te nesto od toga ujesti kad budes hteo ozbiljno da radis. Pre svega zato sto ljudi koji rade npr. security audit vole standarde - zato toliko potenciram na njima.

Prosao sam jednom, pre X godina, PCI DSS i to tadasnji Tier 4 - i pomalo se secam koliko je bio pain in the....

Potpis

Please do not feed the Trolls!

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

Ova diskusija se prilično razvodnila.

Inicijalno pitanje je bilo da li treba fizički razdvojiti baze koje predstavljaju klijentove podatke od podataka za pristup klijentima. A pristup koji je Saja predložio je potpuno pogrešan. Sa stanovišta nekog ko održava bazu sa 10 miliona promena mesečno (a to nije MySql, ali ne vidim neke prepreka da se ne korsisti), koja održava podatke stotina hiljada klijenata mesečno sa desetinama hiljada istovremenih konekcija, jedino što mogu da kažem je da SAJA u startu kreće od nekih nerealnih pretpostavki.

Nema te baze, makar to bio SQLite koja neće brzo vratiti slog kada napraviš upit po primary ili unique key. 95% optimizacije performansi bilo kakve aplikacije koja intenzivno koristi bazu je optimizacija aplikacije (upita), a 5% otpada na tjuniranje i organizaciju baze.

Ono što bih ja razdvojio je deo baze koja se nalazi ispred firewall-a i deo baze koji zahteva kompleksniju zaštitu. Da li svaku fiirmu staviti u posebnu bazu nije bitno. Može biti bitno u smislu nekakvog bekapa i u slučejevim kada firma otkazuje korišćenje usluge. U takvom slučaju realno je pretpostaviti da klijent treba da dobije svoje podatke na neki način. Da li kao export podataka iz baze, što je po meni nepotrebno, ili se za svaki slučaj pravi nekav projekat kroz koji se dogovori format podataka.

Moj predlog, jedna baza kao front end, preko koje se konfiguriše web aplikacija, druga baza koja sadrži finansijske podatke i kojoj se posredno preistupa kroz poseban API.

Đoko, nisam baš razumeo tvoj predlog. Čini mi se da je upravo i predloženo isto kako i ti predlažeš.