Praca inżynierska dobór technologii

Question

Cześć, w tym semestrze pisze inżynierke, jest już pomysł na aplikację ale brakuje doświadczenia w doborze stacku. Praca w grupie rozdzielona na 3 osoby, serwer, mobilna i webowa. Jedyne co wiemy to to że nie chcemy robić crossplatformowej, więc flutter itd odpadają.

Cześć serwerowa ma być napisana w java spring, ma to być api dla aplikacji mobilnej i weba. Pytanie jest takie jak to w ogóle zgrać. Nie znam się na springu więc nie wiem jak to działa, jak rozwiązać kwestię użytkowników, autoryzacji i autentykacji. Chciałem web zrobić w Laravelu, ale nie wiem jak wygląda integracja apki w laravelu z takim api.

 

Wszystkie opinie sugestie mile widziane.

Dzięki za pomoc

Comments

Jedna uwaga od strony (byłego) promotora wielu prac inżynierskich.

Praca w grupie rozdzielona na 3 osoby, serwer, mobilna i webowa.
(...) Cześć serwerowa ma być napisana w java spring, ma to być api dla aplikacji mobilnej i weba. Pytanie jest takie jak to w ogóle zgrać.

Czy te prace mają być ze sobą wzajemnie powiązane? Tzn. jeden z Was robi to API (serwer), drugi robi klienta mobilnego, a trzeci klienta przeglądarkowego/webowego?

Jeśli tak, to kto wymyślił, że Wasze prace mają być powiązane (wzajemnie zależne)? Wy sami? Promotor?

To kiepski pomysł - wystarczy, że osoba od API cokolwiek zawali, a Wasze projekty będą zagrożone.

Kiedy dawałem studentom tematy prac dyplomowych, bardzo dbałem o to, aby takie sytuacje w ogóle nie mogły się zdarzyć. Średni (z wieeelu lat) wynik był taki, że przynajmniej jedna osoba (na 4-6 dyplomantów) decydowała się na obronę w drugim (albo nawet trzecim) terminie (z różnych powodów). Doświadczenia moich kolegów i koleżanek, również prowadzących prace dyplomowe, były podobne.

Wyobraź sobie teraz, że Wasz kolega od API postanowi się obronić w drugim terminie, a Wy będziecie chcieli w pierwszym... (Owszem, technicznie da się to zrobić, ale po co tak ryzykować i dodawać sobie pracy?)

Rozwiązaniem tego potencjalnego problemu byłoby rozdzielenie projektów. Ale to rodzi kolejne problemy (techniczne) dla Was - bo każdy miałby swój własny kawałek API + klienta. Więc albo doszlibyście do porozumienia odnośnie WSZYSTKICH technologii, albo wzięlibyście "rozwód". (Zresztą później integracja tego wszystkiego w jedną całość też mogłaby nie być taka prosta.)
 

---

Słuszna uwaga, promotor sam zasugerował rozbicie i te projekty mają byc zależne od siebie i powiązane. Faktycznie istnieje takie ryzyko i tego się nigdy nie przewidzi, ale współpracuje w grupie, w której już nie raz pracowaliśmy i nie było problemów z terminowością itd.

Co do technologii, jeżeli chodzi o laravel + external api nie ma w cale tak dużo materiałów, więc chyba prostszym i częściej wybieranym rozwiązaniem do takiego problemu jest np node + vue

Answer 1

A myślałeś o .NET 5/6 ? Pozwala na budowę backendu, mobile, desktop. Możesz współdzielić kod za pomocą bibliotek .NET Standard. Koncepcja DDD też jest mega przydatna i bardzo popularna w .NET Core.

W .NET Core masz świetne Identity ułatwiające autentykacje z autoryzacją, do tego ORM w postaci EF Core. Wszystko piszesz w jednym języku C# (nawet jak się uprzesz to apkę po stronie klienta możesz w pełni napisać w C#, tj. Blazor)

Comments

O .necie nie myśleliśmy, ale ja mam już jakieś doświadczenie w laravelu, a osoba od mobilnych w kotlinie i chyba chcielibyśmy zostać przy tym i rozwijać to co umiemy. Ale dzięki za rade

---

API nieważne w czym napiszecie, bo to jest przenośny standard. Jeżeli chodzi o autoryzacje czy autentykacje, to po co Ci Laravel jeżeli piszesz serwer w Springu ? To backend ma odpowiedzialność za te procesy, a rozbicie tego na usługi w dwóch różnych technologiach może Was wprowadzić w kłopot.

Trzymajcie się Javy, Kotlina. Do weba użyjcie w takim razie coś ze stacku React/Angular/vueJS (clien-side)

---

Właśnie to mi się najbardziej gryzło, skoro api ma wszystkie funkcjonalnośvi backendowe to jak to jeszcze z laravelem podzielić. Faktycznie react/vue do wyboru