Razvoj web-stranica - Rasprava

Kako misliš globalne postavke? PHP ima lifespan od jednog requesta. Znači, sve ono što učitaš u jednom requestu je tamo samo taj jedan request. U sljedećem requestu moraš ponovno učitati, bilo iz baze ili iz cachea. Za ono što možeš dobiti iz baze cache ti daje zanemariv benefit, a u nekim situacijama može biti i overhead.

Cache se koristi za resurse koji traže više procesuiranja ili pozive na vanjski API. Primjerice, ako stvari poput default jezika, naziva aplikacije ili sličnog podatka iz baze spremiš u cache, ne dobijaš ništa. Ako imaš tečajnu listu koju povlačiš s HNB-a, onda cacheiranje ima smisla jer ne želiš pri svakom requestu povlačiti vanjski sadržaj i parsirati txt file.

Redis je nešto što ti svakako može riješiti stvar.

Lak za setupiranje, php ima hrpu klijenata za njega (npr https://github.com/nrk/predis) i miran si.

S njim možeš i dobro regulirati invalidaciju:

1) stavit u keš beskonačno i raditi aktivni refresh (npr cron jobom)

2) staviti u keš na određeno vrijeme i raditi pasivni refresh - u smislu da čitaš uvijek cache, a ako dobiješ cache miss onda rekreiraš cache, samo s ovim pristupom pazi ako je rekreiranje heavy, a imaš hrpu upita u tom trenutku onda može nešto otić k vragu :)

Za refresh stanja dionica prvi pristup je dušu dao. Staviš u cache beskonačno, kad povučeš novo stanje refreshaš cache. Easy peasy.

Stanje na skladištu isto tako, updateaš cache tek kad se updatea neki item.

S time da je Redis i puno pametniji od običnog key-value storagea, ima i svoje strukture podataka, možeš LUA skripte pisat za komplexno procesiranje, redundanciju, ali to kad će ti trebat :)

Još jedna bitna pogodnost je činjenica da je Redis ujedno i message broker koji je sposoban javiti klijentima kada je npr. neki key evictan iz cache-a uz vrlo jednostavnu konfiguraciju. Klijent onda očito može nekako reagirati na taj event (refresh cache-a, logiranje, nešto treće, ...).

Kvalitetan klijentski library bi svakako trebao podržavati ove funkcionalnosti.

Konkretno, s obzirom da radim u .NET-u, ovaj library koristi (ako ga se tako konfigurira, naravno) two-level cache gdje je primarni caching provider Redis, a sekundarni živi u RAM-u to jest in-process što znači da se neki key čita iz RAM-a pa tek onda (u slučaju da ne postoji) iz Redis-a te ako tamo postoji ubaci se u RAM cache level dok pisanje ide obrnutim smjerom. Keyspace event-ima se konstantno osvježava taj in-process level (novi key, update, expiry, ...).

Zašto postoji ova opcija? Zato što iako je Redis očito puno brži od SQL dohvata i dalje postoji overhead mreže (može se ublažiti s npr. gzip-anjem koji je super algo za stringove to jest u ovom slučaju 99% JSON, ali naravno da dodatno optereti proc) kao i vrlo vjerojatno deserijalizacija (za čitanje) i serijalizacija (za pisanje).

Recimo da je trajanje dohvata (karikiram ovdje, čisto za primjer) iz baze cca 200 ms, Redisa 20 ms, ali je zato najbrži mogući in-memory dohvat ipak <1 ms (doslovno dovuće referencu na neki objekt s heap-a).

Uglavnom, postoje svakakve mogućnosti. +1 za Lua skripte

Osobno, sve ovo skupa mi smrdi na preuranjenu optimizaciju. Dex, mislim da ti nema smisla uvoditi nikakve dodatne điđe-miđe dok nisi utvrdio da je neki SQL upit (ne mora nužno uopće to biti slučaj) bottleneck u radu sustava. Čak se i u tom slučaju stvari prilično često daju riješiti na DB razini. DB engine-i su jeeeeebeno moćan softver kojeg se može itekako kvalitetno optimizirati (na razini query-ja, sheme baze, ...) ako znaš što radiš.

Ne koriste se bez razloga alati kao što je npr. JMeter koji je 100% besplatan, a jako je moćan.

Jedno je report a drugo je prikaz u UI tijekom rada.

Reporti bi trebali biti izdvojeni (logikom) iz glavne app, neki mikroservis koji bi kao prvo spriječio da neki divlji report ne zakuca glavnu app sa nekim ogromnim upitom. Trebao bi se ponašati kao task - dođe u queue, čeka, izvrši se i javi na UI da je gotov. Ne mora biti real time.

Kreni s MySQLom, nosql za mene dolazi kad je potreban dodatni layer zbog količine podataka, da se olakša pretraživanje/reporti/logiranje.
A InnoDB je tip storagea u MySQLu, nije baza za sebe :) I mislim da je poprično standardan u današnje vrijeme, i za mnoge upotrebe bolji naspram MyISAMa, posebno zbog row-locka, a ne table-locka.

Na početku priče, mislim da se niti ne moraš zamarat s tim detaljima. Kreni defaultno i onda ćeš optimizirat kad za to dođe potreba.

Pa to sam ti napisao, keširat ćeš nazive artikala + kratki opis baš radi takvih stvari.

Ima more autocomplete search primjera na netu, googlaj.

Znam da smaram, no zanima me je li uopće moguće napraviti(ako da, kako?) sustav custom formata broja komponente.

Znači, početni format bi bio A.B

A - ID kategorije u kojoj se komponenta nalazi(do četiri znamenke)

B - Jedinstveni ID komponente(za svaku kategoriju je poseban, do pet znamenki)

Sad me zanima kako mogu napraviti da korisnik može lagano zamjeniti u B.A, ili da doda još neke dijelove, recimo A.B.YY.MM

gdje su YY godina u kojoj je komponenta kreirana, a MM mjesec.

U spuštini:

Kako da povežem da:

A = ID kategorije

B = Broj komponente u kategoriji

YY = Zadnje dvije znamenke godine(2020-> 20)

MM = Mjesec (05)

M = Mjesec (5)

Skužili ste na šta misliš?

Guglao sam, ali jedino na sprintf nailazim(btw, otkrio sam da postoji %1$s, kul stvar).

str_replace je najbolje što sam pronašao trenutno.

Riješeno

$placeholders = array("YY", "MM", "###", "##", "#");
$replace = array(date("y"), date("m"), rand(0, 999), rand(0, 99), rand(0, 9));

echo str_replace($placeholders, $replace, "Dex-YY-MM-###-##-#");

Nije loš taj PHP :D Šteta što Vanilla PHP nije često u upotrebo.

Autocomplete je idealan primjer u kojem je poželjno izbjeći dohvat active recorda ili sličnog oblika. Framework ti i dalje može odraditi buildanje querya, bindanje parametara, ali većina frameworka omogućuje da seletiraš samo polja koja ti trebaju i da dobiješ rezultate kao array. Time značajno štediš resurse, a uz optimalno odabran limit, sve leti.

Za ovo drugo nisam siguran što točno pitaš. PHP-om takav string možeš generirati pomoću strtr funkcije, konkatenacijom stringa, ubacivanjem varijabli u string unutar dvostrukih nazivnika i slično. Razbiti ga možeš regexpom ili splittanjem po točkama.

Ovako na brzinu ne vidim da se igdje koriste col-xs-n i col-sm-n Bootstrap klase namijenjene za uređaje s nižim rezolucijama.

Prouči malo grid system (link je za Bootstrap 3 koji koristiš na site-u, razmisli o upgrade-u na četvorku).

Trebalo bi pomoći, ali nekako sumnjam da će samo to biti dovoljno (obično je navigacija odnosno navbar dodatno zajebavanje, među ostalim). Probaj pa vidi.

Nisam ni ja baš nešto vješt u CSS-u, pričekaj možda nekog tko ima više iskustva s prikazom web site-ova na mobitelima i tabletima.

Dodaš skriptu:

<script src="https://www.google.com/recaptcha/api.js?render=<API KEY>"></script>
<script>
   grecaptcha.ready(function () {
     grecaptcha.execute('<API KEY>', { action: 'send' }).then(function (token) {
     var recaptchaResponse = document.getElementById('recaptchaResponse');
     recaptchaResponse.value = token;
    });
   });
</script>

Uhvatiš u backendu (python, ali nema veze, ideja je tu):

...

sender = 'email@example.com'
subject = request.POST['subject']
message = request.POST['message']
recaptcha = request.POST['recaptcha']
recaptcha_url = 'https://www.google.com/recaptcha/api/siteverify'
recaptcha_secret = '<API KEY>'
recaptcha_send_url = '{}?secret={}&response={}'.format(recaptcha_url, recaptcha_secret, recaptcha)
recaptcha_response = requests.post(url=recaptcha_send_url)
recaptcha_fields = recaptcha_response.json()

if recaptcha_fields['success']:
   email_message = '{} \n\nName: {}\nE-mail: {}'.format(message, name, from_email)
   email = EmailMessage(subject=subject, body=email_message, from_email=sender, to=['recepient@example.com'],)

   email.content_subtype = 'html'
   try:
     email.send(fail_silently=False)
     data = {"response": 1}
     return JsonResponse(data)
   except Exception:
     data = {"response": 0}
     return JsonResponse(data)
else:
   data = {"response": 0, "content": recaptcha_fields}
   return JsonResponse(data)

....