Hejto.pl
Hejto
/Wpisy
/Dyskusja
qarmin
Twórca
w Programowanie
Potrzebuję propozycji na technologie do stworzenia aplikacji dla backendu na serwer i frontendu na komputery i telefony zlecanej zewnętrznej firmie.

Pomagam przy realizacji koncepcji tworzenia aplikacji(mimo że akurat w powyższych tematach średnio się znam), tak by stworzona aplikacja nie kosztowała krocia, działała i by jej rozwój łatwo można było przerzucić na barki innej firmy.

Zapytania o to były wysłane do różnych firm i najczęściej polecanymi techonogiami jest nodejs na serwer, react/react native/nodejs/vue3 jako frontend dla aplikacji jak i również PWA.

Mały problem jest z tym, że akurat doświadczenie głównie mam w komputerowych aplikacjach, więc nie do końca ogarniam wszystkie plusy i minusy poszczególnych rozwiązań.

W skrócie aplikacja to powinno być kilka/kilkanaście ekranów dobijających się do serwera i tam zapisującymi/odczytującymi dane. Raczej nic zaawansowanego - przynajmniej na tę chwilę.

Co do aplikacji na serwer, to myślę że dużo lepszym pomysłem niż NodeJS jest jakaś aplikacja w rust, która zwłaszcza że z racji bycia niewielką(jedyne zadania to autentykacja i zapis/odczyt danych z bazy) nie powinna powodować problemów z długą kompilacją czy zbytnią złożonością a pozwalałaby na szybszy/prostszy deploy i inne ficzery(oczywiście jako zlecacza aplikacji mnie to niezbyt teraz obchodzi to, ale w przyszłości przy aktualizacji/migracji/problemach z wydajnością to mogłoby sprawiać problemy)

Co do aplikacji na telefony/komputer to optowałbym raczej za użyciem Tauri + ts + svelte, zwłaszcza że Tauri 2 beta umożliwia budowanie aplikacji zarówno na windowsy jak i androida.
Tutaj też zastanawiam się nad aplikacją PWA/zwykłą stroną, jednak boję się o jakieś dziwne ograniczenia typu brak możliwości odczytywania linii papilarnych, czy korzystania ze zwykłych funkcji w telefonie(nie znam się, więc to tylko przypuszczenie).
Raczej nie pchałbym się w React na windowsa i React Native na androida, bo to duplikowałoby kod a wolałbym by był on niemal wspólny na tych dwóch systemach, różniący się jedynie rozmieszczeniem elementów na ekranie, a nie technologią

Jest sens się pchać w te technologie, czy może inne byłyby lepsze?

#programowanie
11

Komentarze (11)

ataxbras

@qarmin Sprawdź Capacitor z Ionic.

wombatDaiquiri

@qarmin rób jak umiesz, wy⁎⁎⁎ie się w końcu tak czy siak. Pamiętaj o monitoringu i powodzenia.


Jak chcesz żeby robiła to firma zewnętrzna to niech to robi firma zewnętrzna. Jak Ty masz robić to bierz udziały i bądź wspólnikiem albo nie marnuj swojego czasu.

Catharsis

@qarmin Skoro ogarniasz Rusta to może na front zobacz to, ostatnio mi się obiło o oczy: https://dioxuslabs.com/


A co do backendu to jeżeli to ma być coś małego i z niewielkim ruchem to imo Node.js + jakiś fajny framework (typu Fastify, Nestjs albo Hono) będzie idealny i nie sądze żeby napisanie tego w Rustcie cokolwiek ułatwiło.

Dioxus - Reliable Rust apps that run anywhere

Dioxus - Reliable Rust apps that run anywhere

An elegant GUI library for Rust, inspired by React. Supports Web, Desktop, SSR, Liveview, and Mobile.

Dioxuslabs
qarmin

@Catharsis @wombatDaiquiri

Może nie napisałem tego dość jasno ale to nie ja będę pisał aplikację, tylko będę ją zlecał do zrobienia, więc to co ja znam i w czym mogę pisać jest niezbyt przydatne.


Ja jako osoba techniczna, mam za zadanie jedynie pomóc znajomym by przypadkiem zewnętrzna firma nie szła w kierunku nadmiernych wydatków (np. dwóch aplikacji zamiast jednej) czy też użycia technologii niedopasowanych do wymagań/niemodernizowalnych, których używają od dawna i nie chce im się niczego zmieniać(bo np. póki co wszystko działa).


Dioxus raczej odpada, bo nie widziałem by ktokolwiek go używał i wydaje się trudniejszy niż tauri.

wombatDaiquiri

@qarmin nie ma czegoś takiego i nie polecam cudować. Node + React / React Native powinien wystarczyć. Tak naprawdę robienie znajomego w chuja będzie raczej polegać na pisaniu chujowego kodu albo niedostarczeniu funkcjonalnosci w terminie.


Wycudowana technologia tylko utrudni znalezienie kogoś kto będzie chciał to ugryźć.

Catharsis

@qarmin Na pewno Dioxus jest Trudniejszy niż Tauri bo próbowałem obu i Tauri to po prostu Electron tylko z backendem w Rustcie zamiast Node i bardzo łatwo zacząć cokolwiek w nim pisać.


Więc co do frontu nie pomogę, ale co do backendu to dalej pozostaje przy node.js i jakimś prostym frameworku jeżeli to ma być łatwa i tania w utrzymaniu aplikacja bo właśnie po to powstał node.js co nie. Na 100% prościej i taniej będzie znaleźć kogoś do napisania/utrzymania backendu w Node niż w Rustcie.

lokurva

> aplikacja łatwa do outsourceowania


> rust


wybierz jedno

666

Tauri??


Chopie, kto ci to utrzyma?.


Node.js na serverze, react/next.js na apce webowej ktora bedzie zoptymalizowana na telefony.


Wszedzie JS, technologie ktore zna wiele osob + dosyc latwy stack. Rust jest spoko, ale wez znajdz ogarnietych specjalistow od reki, a w razie jak aktualni programisci zrobia "pa, pa" to szybko ich podmien.


Chociaz przy reactie sie nie upieram bo ostanie zmiany ida w zlym kierunku. Powoli mysle czym zastapic react.

Catharsis

@666 W jaki sposób React idzie w złym kierunku? Serio pytam bo nie widziałem osoby która nie cieszyłaby się na wieści o nowych zmianach które wejdą w następnej wersji Reacta lol

666

@Catharsis odpowiem ci z mojej perspektywy. Robie Backend w node.js, ale ogolnie jestem Fullstackiem. Raz na 100 lat cos na FE zrobie. Co siadam do UI w reactie (w ramach taskow w robocie) to sa grube zmiany, glownie w sposobie managementu stanu i sposobu w jaki stan zmienia UI. Zobacz jaka droge przebyl React:


  • stan w storze przekazywany w props'ach (moze byc to redux). Dodatkowo stan "this.state" ktory uj wie do czego jest. W tej wersji reacta, masz metody lifecycle w ktorych robisz duzo if'ow w ktorych sprawdzasz czy w propsach juz sa dane ktore fetchowales. No lipnie sie to pisalo

  • nowosci: fuction components. Ulatwilo zycie i otworzylo droge do hookow. No ale state w propach juz tutaj nie pasuje, wiec dodajemy contexty - kolejny sposob przechowywania stanu. Czyli mamy contexty, this.state, propsy i pewnie cos jeszcze....

  • na dobre wchodza hooki. Zupelnie zmianiaja sposobw w jaki zmianiamy UI za pomoca stanu. Na tym etapie Ktos kto pisal kod w reactie 2-3lata temu kompletnie nie wie co sie dzieje. Hooki fajne ale duzo rzeczy jest niejawnych, jak np nazwy hookow, trzymanie ich stanu itp - duzo rzeczy trzeba miec w pamieci bo z kodu tego nie wyczytasz. Ogolnie to powinna byc pierwsza wersja reacta w mojej opinii

  • hooki sa passe, tera beda signals'y - kolejna gruba zmiana, kolejny sposob managementu stanu, nie dokonca chce mi sie nawet w to zaglebiac i mysle juz o jakims innym frameworku


Takze programisci core'a reacta sami nie wiedza jak zarzadzac stanem apki, to ja mam wiedziec? Nie wiedza w jakim kierunku ma isc react na co najlepszym przykladem sa sygnaly zgapione od angulara bo taka moda.

666

@Catharsis ktos kto sie jara ze wchodza nowe rzeczy w reactie to pewnie nie musi utrzymywac 3-5letnich aplikacji w nim napisanych bo zeby nie miec apki-dinozaura i updateowac co jakis czas wersje reacta, to trzeba przepisywac pol apki do nowszego standardu bo inaczej zadnej nowej libki nie podepniesz.

Zaloguj się aby komentować