Bo tak się właśnie zastanawiam. Jeśli ktoś chce stworzyć duży projekt w node.js, ale front dać w react.js, to
czy wystarczy w takim projekcie dać jednego klienta react? Czy wie ktoś może jak to się robi w większych projektach?
Czy może jest tak, że tworzy się kilka klientów (np. używając react.js) i po prostu każdy z tych klientów ma trochę inną
frontendową funkcję.
Anyone?
To zależy.
Co chcesz osiągnąć?
Czy może jest tak, że tworzy się kilka klientów (np. używając react.js) i po prostu każdy z tych klientów ma trochę inną frontendową funkcję.
Co to znaczy "trochę inna frontendowa funkcja"?
@LukeJL: Co to znaczy "trochę inna frontendowa funkcja"?
Chodzi o to czy dobrą praktyką jest tworzenie kilku klientów frontendowych (np. reactowych), z których każdy odpowiada za coś innego? (coś innego wyświetla)
Po prostu zastanawiam się, w przypadku większego serwisu (większej aplikacji) czy mogę spokojnie ogarnąć wszystkie widzialne elementy korzystając z jednego i tego samego klienta, czy raczej dobrą praktyką jest utworzenie większej ich ilości.
A także w jakiej sytuacji powinienem utworzyć tych klientów kilka?
Chodzi o to czy dobrą praktyką
Przy pewnej skali "dobre praktyki" przestają obowiązywać, bo masz taką entropię, że wszystko idzie się pieprzyć.
Zbytni monolit to prosta droga do spaghetti kodu i przeinżynierowania.
Zbyt modułowe podejście to prosta droga do big ball of mud, niespójności, duplikacji kodu (i effortu różnych ludzi).
Tak czy siak jesteś w d.
A także w jakiej sytuacji powinienem utworzyć tych klientów kilka?
Lepiej myśleć w kategoriach ogólnych zasad programistycznych, a to, czy klientów będzie kilka, czy jeden, niech wypływa z tych zasad i potrzeb danego projektu.
Np. jeśli klienty robią w zasadzie prawie to samo, to po co je rozdzielać?
Albo odwrotnie - jeśli każdy klient robi co innego, a łączy je tylko to, że pobierają podobne dane, to po co robić z tego jeden projekt?
Ogólnie lepiej sobie stawiać pytania dot. konkretnego przypadku i na nie odpowiadać, niż naśladować jakieś "dobre praktyki".
Możesz mieć jeden backend obsługujący kilka frontendów, ale generalnie tak się nie robi, bo wielu klientów jednego API -> mała elastyczność. Dobrą praktyką jest odwrotne podejście tzw. "backend for frontend", który służy tylko jednemu frontendowi. Taki BFF woła inne backendy (które mogą być wspólną logiką dla wielu frontów) oraz stara się wystawić jak najlepsze API z perspektywy klienta
@slsy: Ok, a co lepiej jest zrobić w sytuacji, gdy chcę mieć dwie całkowicie oddzielne opcje widoków: widok "for all users" oraz widok "only for admin"? Czyli że tak jakby oddzielam od siebie zupełnie front dla zwykłych użytkowników serwisu (forum np.) od frontu osoby administrującej forum, która ma wszystkie uprawnienia? A może nie potrzebne mi są wtedy dwa klienty, bo mogę to rozwiązać inaczej? Czy może po prostu przez właściwą konfigurację routingu?
@finito: w takim wypadku wszystko trzymałbym na jednym froncie. Rozbijanie na mikroserwisy czy mikrofrontendy robi się głównie z tego powodu, że ciężko rozwijać jeden soft przez dużą grupę ludzi oraz po to, żeby mogły rozwijać się niezależnie. Jak to jest twoja samodzielna apka to nawet nie ma się co zastanawiać. No chyba, że dla ćwiczenia.
Wyobraź sobie, że masz backend B i frontendy F1, F2. Wprowadzasz zmianę do B, która jest wymagana do rozwoju F1 jednak jednocześnie ta zmiana nie jest kompatybilna z F2. Jak ogarnąć to wszystko, żeby F1 i F2 działały? Jak masz jeden F to takiego problemu nie ma
@slsy, @LukeJL: Tak sobie to jeszcze przed chwilą zabawnie wyobraziłem. Jeśli backend wyobrazimy sobie jako wnętrze samochodu (np. silnik, elektryka, skrzynia, fotele itd), no to chyba trudno sobie raczej wyobrazić dwie zupełnie różne karoserie tego samego samochodu (???), czyli fronty pochodzące od dwóch zupełnie różnych klientów. Bo jeśli są dwie różne karoserie, to wtedy są też dwa różne samochody. Jednak skoro dwa samochody, to i dwa backendy.
Correct Guys?
@finito: niekoniecznie. Praktycznie każda aplikacja webowa posiadająca wersję mobilną wspiera kilka frontendów: na weba, android i ios. Zazwyczaj w typowej aplikacji crudowej to backend jest królem, bo trzyma dane w jakiejś bazie danych i bez tego backendu nic nie może istnieć. Ale możesz mieć też odwrotną relację np. mamy frontend, który uderza do api zwracającego pogodę i do innego api zwracającego wydarzenia kulturalne jakie się dzieją w danej okolicy. Na podstawie tych danych możemy zaimplementować apkę na froncie służącą do wyszukiwania wydarzeń. Ale również zupełnie inną apkę do wykrywania, czy są jakieś zagrożenia dla danych wydarzeń związane z pogodą. Zauważ, że w tym wypadku backend jest używany jako źródło danych, frontend nic nie zapisuje, więc taki backend jest dużo bardziej elastyczny i reużywalny.
Podsumowując relacja pomiędzy backendem a frontem może być skomplikowana.
slsy napisał(a):
@finito: niekoniecznie. Praktycznie każda aplikacja webowa posiadająca wersję mobilną wspiera kilka frontendów: na weba, android i ios.
Ok, to kolejna sprawa. Czy plugin react-bootstrap lub inny podobny plugin wystarczy, że zrobić wspólny front dla weba, androida i ios?
Czy może jednak trzeba dla każdej z tych opcji wykorzystać inny framework? Bo wiem, że istnieje React Native, ale muszę się w niego jeszcze wczytać. Po prostu nie jestem pewny czy można go używać w tym samym projekcie co normalny react. ??
edit:
@slsy: Ok, coś już doczytałem. Ale twój komentarz też może być pomocny.