Estimare pentru crearea unui Dashboard

Daca se poate, as vrea sa va cer opinia in legatura cu un proiect. Cate zile de development ati estima ca ar lua sa fie creat un dashboard in NodejS (Express) si React?

Specificatii tehnice:

  • typescript, both frontend and backend
  • REST API with Express
  • using Docker containers
  • secret keys used with GCP secret manager
  • protected routes (inside the logged in area)
  • sign up/in with Google
  • rate limiting on auth routes (using Redis)
  • every auth route and form: sign in, sign up, forgot password, reset password
  • email sending
  • subscription payments with stripe
  • licenses created and used after payment
  • deployed to GCloud, both frontend and backend
  • github actions for automatic deplyoment on merge for both frontend and backend
  • MySQL database
  • migrations
  • automated tests on the backed
  • automated tests on the frontend
  • dark and light theme (theme switcher slider)
  • password change form inside dashboard
  • simple dashboard design: menu on the left, content in the middle
  • product cards with buy button
  • SCSS
  • Material UI
  • React Query
  • Responsive
  • using clean code principles
  • using best security practices

Cat spuneti ca ar lua, in mare, realizarea acestui dashboard? Daca ar fi sa-l faceti de la 0, fara sa folositi cod din alte proiecte.

Multumesc!

Eu nu inteleg de ce in cerinte sunt cerinte tehnice precum Material UI, MySQL, Redis, React Query, Docker, REST API with Express, SCSS, GCP Secret Manager…

Proiectele de genul trebuie evitate cu orice pret. Tot ce tine de proiect e cum trebuie sa arate, ce feature-uri (story-uri in mare), cati utilizatori va avea, design-uri/sketch-uri, cu ce se logheaza, permisiuni, plati online… Cand ai un product owner care crede ca stie ce trebuie facut cu ce tehnologie e vai si amar de el, tu ca programator/arhitect decizi ce si cum o sa fie si trebuie sa stii exact de ce.

Sau ai scris tu cerintele pentru noi ?

Pune doar feature-urile, nu tehnologiile mai mereu la estimari. Eu iti zic din start ca in lista aia ai minim 5 combinatii nonsens intre tehnologii in 2024. De fapt o zic asa: express.js il va folosi doar cineva care a citit primul articol de how to build an API in node.js si a zis ca ba ce simplu e.

4 Likes

Cred ca sunt prea putine detalii legate de proiect (ai enumerat doar tehnologiile) incat sa putem estima timpul necesar in mod corect

Este offtopic dar as dori totusi sa imi exprim parerea legata de anumite cerinte din lista ta deoarece multe ar afecta timpul de dezvoltare in mod negativ fara niciun rost:

  • REST API with Express
    • Javascript e foarte slab pe backend. Performanta fiind incredibil de mica si consumul de memorie foarte mare, mai ales folosind una dintre cele mai incete framework-uri de backend (pierzi ~93% din performanta fata de cel mai performant si ~86% din performanta PHP si asta nu ia in considerare proiectele complexe). Poti alege orice altceva si vei avea cam acelasi timp de dezvoltare (Java, C#, PHP sau pana si Rust)… mai ales ca folosesti MySQL drept baza de date
  • using Docker containers
    • Pentru dezvoltare, Docker aduce inca un set de overhead si acum dezvoltatorii vor trebui sa lege containerele de Docker impreuna si sa fixeze anumite probleme. Si, desigur, timpul de dezvoltare creste deoarece vei avea basically un VM pentru fiecare parte a proiectului. Pentru deployment (odata ce ai ceva gata facut, se merita totusi). Pana nu ai zeci de mii de utilizatori pe proiectul asta un singur VM care ruleaza backend-ul si hosteaza frontend-ul nativ e arhisuficient
  • secret keys used with GCP secret manager
    • Fara un motiv bun si concret nu recomand sa folosesti Google Cloud… Ar adauga din nou la timpul de dezvoltare
  • automated tests
    • Ce fel de teste? Unit? e2e? Integration?.. In functie de ce aveti nevoie poate sa aduca mult timp de dezvoltare (initial si la orice schimbare) si poate fi chiar inutil
  • Material UI si Responsive
    • E okay atata timp cat nimeni nu vrea nimic diferit fata de ce ofera framework-ul by default. Daca vrei sa faci modificari va fi mult timp irosit…Se poate face totul mult mai usor cu niste SCSS (deoarece e doar un dashboard) sau sa folositi un framework mult mai simplu cum ar fi Bootstrap. Responsiveness-ul in special va fi mult mai usor de facut daca folosesti SCSS nativ
  • using clean code principles
    • Nu le-as aplica daca este prima iteratie a proiectului si daca proiectul e mai complex. Adauga mult la timpul de dezvoltare fara sa castigi mai nimic. Cateva reguli sunt ok, dar nu trebuie tot codul sa fie “clean”
  • using best security practices
    • Nu cred ca e nevoie mai mult de ceva securitate de baza. Dar, poate proiectul si datele din spate necesita aceasta securitate.
1 Like

Eu o sa fiu mai clar cu clean code principles si node.js, poate poate cu ceva precum NestJS faci ceva mai elegant in node, in rest e crima organizata cam orice proiect cu express. Node nu e rau, nici pe departe, dar trebuie sa stii exact de ce vrei sa il folosesti.

Diavolul sta in detalii :slight_smile:

2 Likes

E vai si amar de programatorul care va colabora cu el. E genul de client de care as fugi si daca n-as avea niciun ban in cont. :smiley:

2 Likes

probabil are deja o oferta, vrea doar sa verifice.

In regula, sa lasam deoparte detaliile.

Cat timp, in mare, v-ar lua sa faceti acest dashboard daca n-am tine cont de tehnologii sau librarii? Doar feature-uri.

Dupa cum a zis @Cosmin_Popescu, diavolul e in detalii.

E.g. * product cards with buy button, how many products si cum arata interfata aia de products ? Filtre/sortare/paginare/infinite scroll/imagini/butoane ?

Wowzies. Practic ce zici tu este ca majoritatea best practice-urilor aduc timp in plus.

Tu nu ai o cerinta, ai doar o posibila implementare.

1 Like

Cu ceva precum Medusa - Building blocks for digital commerce (medusajs.com), React si cerinte bine puse la punct, plus un design bine facut mi-ar lua cam o luna, doua. De la zero e posibil sa ia si un an. (daca vorbim de un produs serios, nu un MVP care se arunca)

Ecommerce si JS e foarte complicat, e mult mai usor daca mergi pe PHP chiar si azi. Sunt solutii pe care le instalezi pe un server, il configurezi si ai tot ce ai scris acolo fara sa scrii o linie de cod.

Da. Uneori e bine sa aplici “best practices”, alteori nu. Depinde de proiect si daca se stie destul de bine cerintele (ceva ce rareori vezi in ziua de astazi, de obicei la o a doua sau a treia iteratie). Zic asta pentru ca in ziua de astazi sunt multe “best practices” care nu prea aduc valoare concreta nici dezvoltatorilor, nici clientilor si nici proiectului.

Din pacate performanta NodeJS-ului e foarte slaba si la chestii simple (see: TechEmpower Framework Benchmarks). Pe langa ca e limitat pe un thread, garbage collector-ul trebuie sa lucreze extra deoarece mult cod (si multe librarii) folosesc programare functionala.

Sigur, il poti folosi, dar voiam sa atrag atentia pierderii de performanta fata de alternative. Daca usurinta in a scrie NodeJS se merita pentru acea pierdere sta la latitudinea dezvoltatorilor

lasand la o parte lipsa specificatiilor functionale, eu as evidentia posibilitatea contractarii separate de consultanta si / sau proiectare / arhitectura software.

evident ca interesul beneficiarului / ownerului nu se aliniaza mereu (ba chiar rar) cu cel al prestatorului, deci cand nu ai suficiente skilluri pentru a alege si gestiona corect poti plati un tert care sa iti traduca si urmareasca interesul tau in situatie.

Mai este o chestie aici ce vad ca multora le scapa.

Alea sunt cerintele. E treaba ta sa le faci. Nu sa schimbi cerintele cand nu-ti convin. Cum ar fi sa-ti puna muncitorul alta faianta ca nu-i place lui faianta pe care ai ales-o.

Mersi de estimare! Este prima pana acum :slight_smile:

Ca idee, estimarea e pentru crearea de la 0 fara a folosi bucati de cod in proiecte anterioare.

Nu trebuie facut un MVP, ci un produs profesional, cu:

  • clean code principles,
  • best security practices,
  • migrations,
  • teste automate (integration tests),
  • deployment automat la merge (prin Github Actions sau altceva),
  • deployment-ul in cloud (GCP, AWS, etc.),
  • rate limiters pentru securitate
  • sign-in with google,
  • un box cu un produs de tip abonament cu mai multe posibile perioade (luna/an) implementat cu Stripe.
  • Design-ul din zona auth a dashboardului foarte simplu, doar 3 menu items,
    • account unde poti sa schimbi parola;
    • settings, unde poti sa schimbi din light and dark theme;
    • subscriptions, pagina cu abonamente, unde iti arata produsul sa-l cumperi daca nu ai deja licenta, iar daca ai licenta iti arata un table cu abonamentul si buton de manage (manage-ul in stripe billing portal - nu trebuie facut)

Ce a insiruit OP-ul nu sunt cerinte ci, in mare parte, tehnologii, si cerintele care sunt sunt doar lucruri de baza pentru orice aplicatie. Nu a explicat detaliile acestui dashboard, ce date va folosi, ce trebuie sa afiseze, despre ce este proiectul, pentru cine e, ce actiuni poti face… etc.

Mi se pare gresita analogia deoarece discutia se refera mai mult la uneltele folosite de catre muncitor nu la materiale sau la rezultatul final. Nu o sa il oblig pe muncitor sa foloseasca ce unelte vreau eu… el stie mai bine.

E un dashboard gol, doar cu ce este specificat in detalii.

Ma intereseaza doar cat v-ar lua ca idee un astfel de proiect sa-l terminati si sa-l aveti ‘deployed in production’. Facand abstractie de client, tehnologii, daca e bine sau nu sa fie facut, sau orice altceva.

Cam pe unde ar fi estimarea?

P.S. Mersi tuturor pentru raspunsuri si implicare.