Soluție laravel + React native

Salutare. Lucrez la un proiect împreuna cu un dev pe React native și suntem intr-o mare dilema. Proiectul este un Fleet management făcut in laravel. Acum se cere și aplicație pe iOS iar beneficiarul a găsit un programator pe React native. Am avut câteva zile de discuții cu acest programator iar el îmi cere sa ii fac un back-End separat pentru aplicație într-un mini framework (ex lumen). Pana aici este ok doar ca as munci eu mai mult și soluția mea ar fi sa ii pregătesc Api-urile direct din aplicatia facuta in laravel fără sa îmi mai bat capul refăcând alt cod pe lumen.
Voi cum ați aborda acest lucru?

Intreaba-l dc vrea in lumen

Works every time

1 Like

Nu îl interesează framework-ul. A menționat lumen fiindcă eu lucrez cu laravel

1 Like

Atât timp cât endpoint-urile tale dau datele corect, în formatul stabilit (JSON?) și raspund într-un timp rezonabil, nu cred că are importanță dacă tu mai faci niște controllere în Laravel sau o aplicație separată.
Cel mai probabil a propus un microframework pentru o performanță mai bună. Fară să stiu mai multe despre aplicație e greu sa vin cu argumente pro sau contra.

Incearca sa afli de ce are nevoie de alt back-end, poate are nevoie de niste date agregate, sau ce nu este suficient sau compatibil.

Patternul se numeste BFF (Backend For Frontend). Se refera la faptul ca pe web/desktop ai nevoie de raspunsuri cu mai multe date, in timp ce pe mobil ai nevoie de versiuni lightweight ale aceluiasi microserviciu (in caxul tau backend).
Exemplu: GET “/user/7” poate necesita adresa in raspuns pt eeb, doar numele pe mobile

6 Likes

E vorba de comunicare. Cine va conduce proiectul? Daca exista endpoint-uri el trebuie sa le foloseasca si sa se “muleze” pe solutia ta, pentru a putea livra proiectul.
Daca ii faci un API nou, tu va trebui sa te ghidezi dupa cerintele lui.

Este API-ul tau documentat(swagger), usor accesibil, usor de folosit?

Poate avea nevoie de mai multe, mai putine sau de cu totul alte date pentru mobil, insa back-end-ul foloseste ce tehnlogie vrea.

Am avut la un moment dat o situație asemănătoare: aplicație mobilă ce consuma un API. Ambele scrise de la zero, eu mă ocupam doar de aplicația mobilă, dar comunicam tot timpul cu programatorul de backend. Am procedat așa:

  • Eu făceam niște răspunsuri-mock (în Apiary) iar toată aplicația interoga apiary.
  • Programatorul backend urmărea mock-urile din Apiary și le implementa corespunzător. E.g. știa că /user trebuia să returneze profilul utilizatorului logat, /search?q= era endpoint pentru căutare șamd. În total erau în jur de 30 de endpoints, majoritatea (să zic 20-25 dintre ele) acceptând mai multe metode (GET/POST/PATCH/DELETE).

Domeniul pe care se faceau interogările putea fi schimbat la build și cam aia a fost tot.

Eu mi-am văzut de treabă și după vreo două luni (cu câteva zile înainte de lansarea live!) am testat pe serverul real. Practic eu am scris aplicația folosind doar acest tool, nu m-a interesat nici măcar un moment ce se folosește pe server. :slight_smile:

3 Likes

Ciudat. De ce îți impune cum sa faci arhitectura de backend omul de pe frontend? Dpdv-ul lui e ceva invizibil asta - are niste endpoint-uri și le apelează cf unui contract. Restul e treabă ta, și ai tu contextul maxim sa faci decizia.

Și chiar daca era unul pe backend, sa ai un serviciu nou nu-i de ici de colo. Tine-o monolit cat poți.

În cazul meu a fost o situație mai aparte. Eram cumva contra timp, omul de pe backend era prins cu altceva și ar fi trebuit să aștept cel puțin 2-3 săptămâni după el.

În plus, omul nu era extrem de familiar cu REST (ca și concept) sau cu servicii RESTful, deci aș fi sfârșit cu … cine știe ce backend. :smiley: Privind în urmă, pot spune că a fost avantajos pentru toată lumea modul ăsta de lucru.

Oricum, mi se pare normal ca cel care consumă un API să definească endpoints, nu cel care produce acel API. Nu?

All in all, abordarea mea nu impune nici un fel de arhitectură; setează doar interfața. Implementarea nu depinde de mine.

Sau pui graphql :slight_smile:

1 Like

Discutand cu el și cu clientul am avea doua opțiuni:

  1. Sa ii livrez Api din aplicatia principala folosind api Resources și Collections in așa fel încât sa ii returnez doar datele necesare
  2. Sa mergem pe soluția propusă de el cu un back-end separat făcut într-un microframework având in vedere ca s-a cerut și a doua aplicație pe mobile și plus ca nu ar avea nevoie de foarte multe date. Auth, câteva get-uri și câteva post-uri.

Varianta a doua ar însemna mai mult de munca dar și mai mulți bani :grin:

Voi pe ce varianta ați merge? Pana la urma nu este vorba de bani, pe mine ma interesează sa iasă ceva cât mai profi și mai ok ca bani voi câștiga in continuare dacă clientul este mulțumit.