Dilema dashboard app


#1

Salutare.

Am un proiect la care voi avea nevoie de un admin panel (exclus voyager etc), ceva facut de la 0. Dilema mea ar fi daca pentru acel dashboard sa fac o aplicatie separat folosind aceleasi obiecte si aceeasi DB sau sa fac ceva de genul wordpress (folder wp-admin)?

Voi cum ati proceda? :slight_smile:


(István F.) #2

Gasesti panouri gata facute in vue/react/angular.
Trebuie doar sa implementezi logica, in general cele mai complexe parti dintr-un panou de admin sunt permisiunile/grupurile, continutul dinamic (WYSIWYG) si log-urile. Rutarea te mai poate incerca daca ai multe optiuni dinamice intr-un tree in meniu.


(Eduard-Dan Stanescu) #3

Folder separat, eventual sa nu aiba treaba cu aplicatia.
Foarte multi developeri nici macar nu isi mai construiesc partea de administrare, totul fiind editat direct in SQL, in caz ca au nevoie sa umble la ceva (depinde si cat de mare este proiectul tau).


(Georgiana Gligor) #4

din frontend?! pai si cu securitatea ce facem?


(Florin Frătică) #5

Cred că @zshare spune că programatorul rulează un query SQL într-un GUI (ex. MySQL Workbench) pentru a modifica informațiile din baza de date, la cererea clientului.


(Catalin Ionut Titov) #6

Din moment ce ai mentionat voyager banuiesc ca e in php aplicatia. Nu l-am folosit dar recomand orice tool care iti rezolva deja problema.

Legat de intrebarea ta cel mai bine este o organizare pe 3 foldere. Partea comuna ambelor sa fie intr-un folder, insert/select/etc vor fii folosite si in frontend si in backend. Si la sfarsit doua foldere frontend/backend cu particularitatile fiecaruia. Tot ce e comun poate fi pus in acelasi folder, cel initial.

Totusi un admin panel iti rezolva o parte din probleme, ca doar de asta a fost creat.


#7

Am scris in graba maxima și am uitat sa precizez ca aplicația este scrisă in Laravel


(Florin Frătică) #8

Eu în aplicațiile pe care le-am dezvoltat (tot în Laravel) am preferat să fac panoul de administrare în aceeași aplicație. L-am separat grupând rutele specifice într-un namespace.

Motivele sunt următoarele:

  • deployment-ul aplicației se face automat, dintr-un repository și mi s-a părut mai intuitiv ca panoul de administrare să fie în acel repository
  • dacă aveam două repository-uri, fiecare cu o instanță de Laravel, ajungeam să duplic cod (de exemplu pentru modele) și devenea greu de maintain-uit sau ar fi trebuit să fac un repository care să conțină codul comun și pe care să îl pun în composer.json la ambele aplicații, dar mi se părea că mă complic
  • în momentul în care modific o entitate nouă se iau anumite acțiuni. De exemplu, într-un CRM dacă modific setările unui tip de tarifare trebuie să actualizez suma facturilor planificate (am folosit Observers pentru asta).
  • mi se pare greșit ca două aplicații să aibe dreptul de a modifica aceeași bază de date. Am dreptate? Mă gândesc că dacă apar date corupte trebuie să te uiți în ambele aplicații nu într-un singur loc. Când m-am lovit de situația asta am preferat să fac un API și a doua aplicație să interacționeze cu API-ul nu direct cu baza de date.

De asemenea, nu am folosit vreun admin panel. Motivul principal este că nu au fost multe CRUD-uri de scris, dar sunt și foarte customizate și nu știu dacă aș fi putut să le fac cu un admin panel.
De exemplu, un CRUD a fost făcut similar cum e în phpmyadmin insert-ul din interfață a înregistrărilor, adică selectezi câte înregistrări vrei să adaugi și îți apare o secțiune de formular pentru fiecare înregistrare în parte. Asta pentru că erau multe insert-uri de adăugat.
Aici, dacă are cineva experiență cu admin panel-uri poate ne poate ajuta cu o idee. Cât de mult se poate customiza (desigur depinde și ce admin panel folosești)?

P.S.: Dacă nu greșesc, Laravel Backpack este dezvoltat de un român și era activ pe forum aici, la un moment dat.


(Andrei F.) #9

Exceptand cazul in care aplicatia e una foarte mare si compusa din mai multe (micro)servicii, cred ca nu merita sa te incurci cu o aplicatie separata pentru zona de admin.

Iti recomand sa arunci o privire peste backpack. Am lucrat la un proiect cu el si mi s-a parut mana cereasca. Ofera o multime de campuri out-of-the-box si optiuni de configurare, fiind sanse destul de mari sa nu ai nevoie sa-l extinzi desi si asta e destul de usor de facut (datorita structurii sale si a documentatiei destul de bine puse la punct)

Fun fact: Backpack e opera lui @tabacitu