acolo m-am uitat prima data, insa preturile sunt ceva mai piperate decat ce ofera competitia, iar configuratiile par mai scazute. ca o gluma, dubla inflatie 
sqlite e o soluție f bună pt ce nevoi ai tu (n-am experiență cu .net, thou)
(s/vrei/ce nevoi ai/)
.NET se gazduieste si pe Linux in ziua de azi.
MSSQL asemenea, dar e overkill pentru o baza de date asa mica unde banuiesc ca nu faci nimic deosebit.
5 Likes
baza de date, dupa ce aduc clasamentul la zi (ultimii 5 ani de rezultate), o sa ajunga pe la 50mb cred. Dupa asta, o sa adaug in jur de 15k, 20k linii de rezultate anual doar pentru viitoarele competitii (pentru 15.000 vad ca tabela ocupa in jur de 5mb). daca o sa creez concursuri de pronosticuri de tip sezoane (1-2 luni) si ajunge sa aibe macar 100 useri care participa zilnic, dbul o sa creasca suficient, banuiesc ca ajunge la cateva sute mb in 2 3 ani (+continuare extindere aplicatie). Am mers cu mssql pentru rapiditate in dezvoltare, fiind compatibil cu entity framework si folosindu-ma de migrari, am scapat de multa bataie de cap.
ca hosting, m-am decis sa raman la contabo. s-ar putea sa fie mult pentru inceput, insa pretul este bun (37e pentru primele 3 luni + 10e pe luna) pentru configuratia urmatoare: 6 cores, 16gb ram, 400gb ssd, ubuntu (v22.04 sau v20.04).
Pare ca trebuie sa fac upgrade la .NET 6, deoarece ce e sub nu mai e compatibil cu ubuntu 22.
cu 16gb ram, ma gandesc ca pot tine suficiente date in memorie cat sa le pun la dispozitia frontendului intr-un timp cat mai scurt (exemplu pentru prima pagina, sau clasamentul curent, pot tine un top500 echipe in cache).
am uitat de SSR, aplicatia generata are deja 200mb pentru doar 1000 echipe inregistrare pana acum (trebuie sa ajung undeva la 5000). practic, sunt deja 3 aplicatii angular, cea cu SSRul apropiindu-se de 1gb intr-un final.
La 50 MB baza de date, poti tine si totul ca un json in memorie si tot nu se simte.
1 Like
Nu stie genera pe loc? Trebuie sa stocheze toate variantele pe disc?
inca nu-mi dau seama, pentru ca n-am luat domeniul, iar cu subdomeniile, google penalizeaza, de 2 saptamani ma chinui sa indexez cateva pagini, mi-a luat doar homepageul. Si asta pentru ca am date statice, salvate intr-un json (nu fac api calluri), pe subdomeniu de netlify. Iar pachetul pe care-l urc pe host e cel generat dupa comanda npm run prerender, pentru a putea fi indexate de roboti (am si sitemap.xml cu toate rutele si toate paginile ce sunt create pentru ssr).
Deci nu mai folosesc ng build --prod pentru pachet, ci il iau direct pe cel generat de prerender, care include si ssr. nu stiu daca-i cel mai bine, dar pare ca functioneaza dar din ce am testat zilele astea, pare ca eu nu am pornit aplicatia de SSR, aceea trebuie rulata de nodejs si ca punct de intrare are server/main.js
acum, ca sa generez pe loc paginile, cand robotii acceseaza, probabil e nevoie ca acestia sa treaca prin sitemap mai intai, sa stie ce pagini exista. Problema e ca acel sitemap e generat automat fix dupa paginile rezultate in urma prerenderului, cauta in aplicatie dupa index.html, iar cum fiecare pagina cu ssr facut are un index.html, genereaza link in sitemap.
Chiar am văzut recent un talk ținut de Scott Hanselman care vorbea de blogul lui și ținea toată baza de date a blogului sau (300mb) în memorie pt ca why not, memory is cheap. Backing store era un fișier json. Link
1 Like
peanuts.
tre sa aiba continut, si sa fie diferit de la o pagina la alta. Google a devenit selectiv cu ce rahaturi indexeaza.
1 Like
continutul incerc sa-l verific pe diferite siteuri de seo.
am reusit cumva sa structurez paginile astfel incat sa contina si headere, si ceva paragraf, text minim 500 caractere.
La server e 0% momentan, trebuie sa-i fac compresia gzip, implementat ssl si redirect catre un singur tip de link (https://domeniu). Nu m-am hotarat la domeniu :)))
Aplicatia poate fi accesata pe ip momentan, cu date hardcodate (http://173.249.28.126:4000). e pornita ca o aplicatie de nodejs (m-am folosit de compression de la npm in server.js (inainte de build) dar pare ca nu merge. ori functioneaza doar in cazul http requesturilor, ceea ce nu e inca cazul - ma gandeam ca se aplica si pentru imagini tinute in aplicatie). Altfel, daca nici asa nu functioneaza, ma gandesc sa instalez nginx, configurez nginx pentru compresie si tot cu el pornesc si aplicatia. S-ar putea sa vorbesc balarii, m-am folosit de screen pentru a rula o aplicatie node in background si asa n-am avut nevoie de un alt server pentru a o porni. Insa imi pare ca toate configuratiile care trebuiesc sa aibe loc pe server sunt nevoit sa le tin in main.js).
ma gandeam, la cate miliarde de siteuri exista … e greu sa ajungi in primele pagini acum 
daca reusesc sa trec de politica wikipedia de a sharui linkuri, o sa am in jur de 5000 backlinkuri de acolo, asta ar ajuta enorm.
afaik link-urile de pe wikipedia au rel="nofolow", nu cred că ajută la SEO
cred ca toate forumurile au lucrul asta, nu voiam sa-i fac reclama, ci sa pot primi pareri. Am generalizat subiectul, de la tehnologie la hosting, apoi la continut/seo 
legat de hosting … am vrut ubuntu ultima versiune, dar inca n-are compatibilitate cu mssql (nu m-am obosit sa verific inainte), o solutie ar fi docket in ubuntu si mssql in docker 
altfel, pare ca mai e nevoie de 2 fisiere in plus pentru a reusi instalarea (am gasit ceva articol pe forumul microsoft).
per total, sunt chestii pe care le invat aici, chiar daca nu cred ca o sa ajung sa lucrez la vreo companie pe un proiect angular ce necesita SEO, pentru mine e “nice to have”. Ah, cu achizitia de hosting, deja e cel mai avansat proiect personal 
lasa ca este ok
decat sa citesc depsre bisnitari si salarii de 8 mii de euro prefer acest thread 
Succes cu proiectul si sa il vedem live
PS: nu-s expert in seo dar poti sa pui si un nume unic. Eu am Chestii automate si stau bine in Google. Inclusiv forumul apare cu spamul meu 
1 Like
Revin si cu updateuri, cred ca transform postarea in jurnal M-am jucat putin cu aplicatia de client, i-am dat culoare paginii de detaliu a echipei (unpic prea multa cred). In spatiul gol din stanga sus o sa pun trofee si performante din ultimii 5 ani pentru fiecare competitie la care a participat.
ce-mi pare dubios, aplicatia fiind randata cu SSR, poti vedea doar echipele care au o pagina generata. Astfel, daca introduc in baza de date o echipa noua, fara sa reexecut prerenderul, sa-mi genereze pagini si pentru datele noi, aplicatia o sa redirectioneze catre homepage.
lucruri noi invatate: am configurat nginx sa bata catre api si web, am reinstalat ubuntu pentru ca blocasem total accesul activand nu stiu ce firewall. Un lucru bun, ca am putut face downgrade de la v22 la v20, care e compatibila cu sql server si nu trebuia sa mai instalez docker, sql server in el si sa configurez docker volume ca sa am storageul duplicat si pe server. De lene/timp putin, inca fac deploy manual cu scp local remote si sterg pachetele/repornesc aplicatiile din linie de comanda (o sa-mi fac ceva scriptulete sh mai incolo, sa faca toate astea).
oh da… si am reusit din SSMS local sa ma conectez la sql remote, e genial, pot importa in 2 minute baza de date locala in productie.
alta chestie despre SSR, cand fac prerender, spameaza api-ul cu vreo 5000 requesturi in 10/15 minute…oare asta ar trebui sa fie o problema? pentru ca, ca sa-si construiasca continutul paginilor, are nevoie de datele de pe backend. Momentan n-am loguri puse pe endpointuri, dar cand le-oi pune, ar trebui sa filtrez eventurile de genul asta, sa nu fie luate in considerare. Probabil pot face asta din server.js, sa-i pun un header pe care sa-l ignor in api. 
2 Likes
Sunt oameni interesati sa vada grafice cu statistici ale cluburilor?
Cu siguranță că vor sa vadă comparații intre cluburi, însă ma surprinde sa vad că se uite la grafice.
SQLite nu te-ar multumi cu schimbari minime in cod?
Ai dreptate, însă nici n-aș vrea să-l fac la modul doar informații tabelare. Plus ca datele sunt mai mult agregate, n-o sa am statistici pana la nivel de meci. O sa mai umblu la culori (ma gândeam la ceva mai fad, de toamna, nu un curcubeu), poate le mai restrâng ca dimensiune. Cu cât aduc mai multa informație pe pagina, cu atât trebuie sa restrâng pe cele actuale, însă trebuie avut grija și cu asta, pentru ca în același timp, trebuie păstrat și un format simplu și ușor de înțeles.
Dani, momentan îmi ia foarte mult timp sa introduc datele pana ajung cu clasamentul la zi, pe lângă micile dezvoltări, descopăr particularități în unele competiții ce au nevoie modificari în cod, iar schimbarea bazei de date nu-i prioritara. Ce știu sigur, e ca va trebui sa scriu queryurile de mana pentru selecturi, altfel așteptarea după Entity Framework va deveni un chin. Clasamentul general îl am salvat în memorie, însă pentru unele pagini mai în detaliu, trebuie sa sap in tabela de rezultate, sa filtrez și sa prepar datele, e un proces lent, ce necesita multe agregari și transformări.
Când o ajunge publica, pentru echipele cu frecventa cea mai mare de vizitare, voi tine toate datele astea deja pregătite în memoria api-ului,
update:
- am pus serverul cat de cat la punct;
- am cumparat domeniu https://footballalphabet.com/ in cele din urma , reusit sa instales si ssl pe server;
- am mai peticit designeul cat sa nu supere ochiul prea mult, la accesare (nu mai avem chartul ala mare pe pagina echipei, cum zicea si George, nu e chiar domeniul pentru care ai vrea sa vezi cardulete si dashboarduri);
- SSR pare ca functioneaza, in aproximativ 3 zile, am in jur de 1000 pagini indexate pe google. Ieri am facut debug jumatate de zi (inutil), pentru ca vrand sa instalez disqus pe pagina echipelor, aveam nevoie de url si am lasat un “window.location” in cod, lucru ce nu e stiut de SSR si nu-mi mai construia html-ul pentru 5000 rute, practic ce era mai important
am tot verificat scorul seo, e undeva intre 70 si 80% pentru fiecare pagina, mai e de crescut.
performanta: e dezastru, viteza de incarcare lasa de dorit, sunt cateva lucruri importante de modificat:
a) frontendul:
- sute de imagini salvate in assets, va trebui sa le mut intr-un cloud (cloudinary am mai folosit in trecut si cred ca ramane si acum); // de aici primesc si penalizare seo;
- codul: trebuie rescris in mare parte, componente de reutilizat si mai ales stilurile. observabilele n-au unsubscribe pe nicaieri 
b) backend: de aici sper sa vina cea mai mare optimizare. folosind Entity Framework pentru selecturi uriase, timpul de asteptare e imens. Nici macar AsNoTracking() nu ajuta, atunci cand am in jur de 3 tabele, fiecare cu cate 20.000 linii si trebuie sa fac diferite grupari pe ele. Am mai folosit ProjectTo de la AutoMapper, dar doar acolo unde am nevoie de date asa cum sunt in db, fara prea mari modificari (si doar pentru o entitate, nu lista). Astfel, din cate stiu, cea mai performanta metoda e scrierea queryului ca string si executarea lui cu EF sau ADO. Cu ocazia asta, imi pot crea si un DataAccess layer, ca pana acum tineam tot in servicii.
Asa imi dau seama cat de mult conteaza o echipa. Un milion de idei si timp limitat, dar cel putin pana aici am invatat o groaza de lucruri si sunt convins ca voi invata in continuare daca ma tin de proiect.
2 Likes