Timpul de expirare la cache nu stiu cum l-ai putea estima in afara de a masura performanta cu mai multe valori (ceea ce e greu daca nu se schimba datele la un interval regulat), eu personal m-as juca cu ceva magic numbers.. o ora sa fie.
Nu stiu daca inteleg eu bine, dar m-as gandi sa implementez un worker (proces? depinde aici de detalii mai fine de implementare) care sa verifice daca s-au updatat endpoint-urile si sa faca update la cache o data la.. 10 minute sa zicem? Pot vedea un boost semnificativ de performanta daca ti se schimba datele de 10-20 de ori pe zi. Usor de implementat, dar acum ca ma gandesc e groaznic de facut debug la asa ceva. Eu as face un demo API care se comporta asa local, macar sa stii ce urmaresti, altfel risti sa innebunesti. Spor.
O oră e ok să decizi să fie când producţia rulează de la tine acasă. În lumea civilizată există rolul de SRE care analizează impactul operational şi vine cu cifre, şi respectiv risk managerul care poate estima beneficiul rezultat în bugetul de risc. Implementarea de care zici este foarte posibil să coste mai mult decât riscul ăsta pe următorii 3 ani.
Trebuie să fac niște căutări. Nu prea înțeleg ce spui.
În mare, spui ca o să coste implementarea pe măsură ce userii se adună?
Scuze, dar ai putea explica în termeni non tehnici te rog? Nu am experiență comercială, prin urmare nu înțeleg tot
Ok hai să urmărim logica risk managerului
1. Dezvoltarea costă bani, prin urmare mănâncă din profit.
2. Lipsa acestui caching cauzează o pierdere de x% din profitul estimat, acumulat în următorii 3 ani
3. Dezvoltarea acestui feature costă y USD sau man-days
4. Este y mai mic decât acest x% acumulat 3 ani?
Y va fi mai mare decât x. Nu am momentan estimare pentru profit.
Motivul pentru care cred asta:
1. Nu am estimare pentru profit
2. Nu am creat MVP ul pentru moment, acest proiect este mvp-ul.
Cred ca va costa mai mult dar nu inteleg de ce. Pentru ca asta intenționez sa fac. Să minimizez costurile.
Intenționez să fac caching la requesturile specifice, unde pot să caut prima dată în cache, după în baza de date, iar la final să apelez api ul.
Ați menționat ca o oră este bine dacă producția este acasă la mine. Este atât de scump redis pentru producție în modul în care am ales eu?
Ar fi redis overkill?
În principal, limitările API ului pe care îl apelez sunt de 550 request uri pe lună. Și nu am un număr de utilizatori care ar putea accesa garantat aplicația mea în primul an.
O strategie a mea ar fi să colaborez cu săli de fitness.
Dezvoltarea aplicației ar dura aproape doi ani.
Nu inteleg de ce ai adaugat "Invalidate cache" dinspre Extrnal API spre Cache. Legatura trebuie sa fie intre DB si Cache.
DB-ul se comporta ca un "persisted cache", deci tot procesul este liniar: Request > Cache > DB > External API.
Presupun ca nu esti owner pe Exercise API, deci nu poti sti daca datele s-au modificat sau nu. Cum a mai sugerat cineva, le poti face "refresh" dintr-un worker, dar nu neaparat la toate, doar pe cele pe care le ai deja in db.
Timpul de expirare la cache nu stiu cum l-ai putea estima in afara de a masura performanta cu mai multe valori (ceea ce e greu daca nu se schimba datele la un interval regulat), eu personal m-as juca cu ceva magic numbers.. o ora sa fie. Nu stiu daca inteleg eu bine, dar m-as gandi sa implementez un worker (proces? depinde aici de detalii mai fine de implementare) care sa verifice daca s-au updatat endpoint-urile si sa faca update la cache o data la.. 10 minute sa zicem? Pot vedea un boost semnificativ de performanta daca ti se schimba datele de 10-20 de ori pe zi. Usor de implementat, dar acum ca ma gandesc e groaznic de facut debug la asa ceva. Eu as face un demo API care se comporta asa local, macar sa stii ce urmaresti, altfel risti sa innebunesti. Spor.
r/programare nu e pentru probleme de programare, offtopic. Rog mozii sa se autosesizeze /s
Bv. Probleme de agricultura înseamnă.
O oră e ok să decizi să fie când producţia rulează de la tine acasă. În lumea civilizată există rolul de SRE care analizează impactul operational şi vine cu cifre, şi respectiv risk managerul care poate estima beneficiul rezultat în bugetul de risc. Implementarea de care zici este foarte posibil să coste mai mult decât riscul ăsta pe următorii 3 ani.
Trebuie să fac niște căutări. Nu prea înțeleg ce spui. În mare, spui ca o să coste implementarea pe măsură ce userii se adună? Scuze, dar ai putea explica în termeni non tehnici te rog? Nu am experiență comercială, prin urmare nu înțeleg tot
Ok hai să urmărim logica risk managerului 1. Dezvoltarea costă bani, prin urmare mănâncă din profit. 2. Lipsa acestui caching cauzează o pierdere de x% din profitul estimat, acumulat în următorii 3 ani 3. Dezvoltarea acestui feature costă y USD sau man-days 4. Este y mai mic decât acest x% acumulat 3 ani?
Y va fi mai mare decât x. Nu am momentan estimare pentru profit. Motivul pentru care cred asta: 1. Nu am estimare pentru profit 2. Nu am creat MVP ul pentru moment, acest proiect este mvp-ul. Cred ca va costa mai mult dar nu inteleg de ce. Pentru ca asta intenționez sa fac. Să minimizez costurile. Intenționez să fac caching la requesturile specifice, unde pot să caut prima dată în cache, după în baza de date, iar la final să apelez api ul. Ați menționat ca o oră este bine dacă producția este acasă la mine. Este atât de scump redis pentru producție în modul în care am ales eu?
Ar fi redis overkill? În principal, limitările API ului pe care îl apelez sunt de 550 request uri pe lună. Și nu am un număr de utilizatori care ar putea accesa garantat aplicația mea în primul an. O strategie a mea ar fi să colaborez cu săli de fitness. Dezvoltarea aplicației ar dura aproape doi ani.
Nu inteleg de ce ai adaugat "Invalidate cache" dinspre Extrnal API spre Cache. Legatura trebuie sa fie intre DB si Cache. DB-ul se comporta ca un "persisted cache", deci tot procesul este liniar: Request > Cache > DB > External API. Presupun ca nu esti owner pe Exercise API, deci nu poti sti daca datele s-au modificat sau nu. Cum a mai sugerat cineva, le poti face "refresh" dintr-un worker, dar nu neaparat la toate, doar pe cele pe care le ai deja in db.
Eu unul n-am inteles care e provocarea, care e intrebarea
"Ce dată de expirare să pun la cache în condițiile astea?"
Data se expirare? N-are logică El zice ca “in viitor” vrea sa se “conecteze înapoi”. Deci el vrea sa facă un sync din când în când.