Witam, mam problem organizacyjny. Zastanawiam się jak powinna wyglądać praca nad projektem angular + web api(w moim przypadku jest to .net core).
Visual studio daje możliwość wygenerowania projektu który zawiera api .net corowe z wrzuconą od razu strukturą aplikacji angularowej, takie samo podejście spotkałem już w kilku kursach w internecie, jednak parę rzeczy każe mi zastanowić się czy to aby na pewno najlepsze wyjście.
Jeszcze jakieś 2 miesiace temu jak zaczynałem dłubać w tej technologii pierwszym problemem przy tworzeniu projektu był brak pliku angular-cli, trzeba było go skopiować z innego projektu czysto angularowego, kolejnym problemem było instalowanie bibliotek, często musiałem improwizować na różne sposoby.
Na chwilę obecną struktura tworzonego projektu nieco się zmieniła, jednak zastanawia mnie np czemu projekt generuje mi cli "angular-cli.json" a nie po prostu "angular.json", przecież "angular-cli.json" to jego starsza wersja.
Tak więc, zastanawiam się czy nie powinienem po prostu do problemu podchodzić tak że będę zakładał osobny niezależny projekt web api(autoryzacja, database itd), i zupełnie inny projekt angularowy który będę już sobie odpalał osobno przez ng serve.
Czy może ktoś przybliżyć mi jak wygląda profesjonalna praca z tymi technologiami? i ogólnie angular + web api? Wydaje mi się to trochę dziwne, bo .net core może się zmieniać, angular cli może się zmieniać, i za każdym razem trzeba będzie jeszcze czekać aż ludzie od visual studio dograją te zmiany, a jak widać póki co nie nadążają.
Zgadzam się z Twoimi obawami. Taką samą sytuację miałem w przypadku .NET Core + React. Po utworzeniu projektu musiałem poświęcić chwilę na ogarnięcie szumu organizacyjnego.
Ogólnie uważam, że tego typu "szablony" są na swój sposób irytujące, ponieważ nie masz pełnej świadomości zależności które znajdują się w projekcie. Lepszym rozwiązaniem jest (tak jak twierdzisz) stworzenie "czystej" aplikacji .NET Core oraz "czystej" aplikacji Angular. Tylko wówczas masz gwarancję, że zależności oraz struktura projektu w pełni odpowiada Twoim potrzebom.
Szablon ma to do siebie, że jest jakąś tam wypadkową najpopularniejszych scenariuszy. Poświęcenie czasu na zagłębienie się w strukturę takiego projektu i dostosowanie go do swoich potrzeb na pewno się opłaci w postacie lepszego zrozumienia działania całej aplikacji. Z mojego doświadczenia wynika, że lepiej jest dostosować wygenerowany szablon niż robić wszystko od zera.
Stworzenie od zera projektu angularowego i skonfigurowanie go jest dość proste. Zdecydowanie wolałbym to niż mieć ew. problemy z tym wygenerowanym. No i w dodatku i tak nie będziesz przecież pracować z frontendem w visualu. Już bym chyba wolał notepad++.
Kupiłem kolejny już kurs .net core + angular, najlepiej oceniany na udemy, tym razem prowadzący podchodzi do tematu właśnie w sposób budowania dwóch oddzielnych aplikacji.
Jedyna rzecz jaka mnie zastanawia, taka która przemawia przeciwko podejściu budowania dwóch osobnych aplikacji to deploy tego na server. Musimy wrzucić dwie osobne apki, i zarezerwować dwa porty a nie jeden, nie znam się za bardzo na konfiguracji i wrzucaniu tego, ale czy to nie jest duży i istotny problem?
Zarezerwowanie dwóch portów nie jest problematyczne. Mozesz miec te dwie aplikacje na jednym serwerze, ale lepiej jakby byly na odzielnych. A jeszcze lepiej jak na kilku. Ale 2 wystarcza, od biedy 1.
A nie lepiej te dwie apki dać w docker-compose?
Moze, ale to mu pomoze tylko lokalnie. Na produkcji i tak bedzie musial jakos to ogarnac, wiec dochodza dodatkowe zaleznosci.
Szczerze nie korzystałem nigdy z docker'a i bardzo mało o tym wiem, rozumiem że miałoby to działać tak że te dwie apki wrzucałbym w dockera, a później już razem hostował tylko ten kontener z jego zawartością(tzn. tymi obiema apkami), tak?
U nas tworzymy paczki z aplikacją (.net core 2) przez Publish w visualu. Mamy skrypt prepublish który buduje aplikację do folderu wwwroot. Także są to 2 osobne aplikacje ale później idą jako jedna.