W powyższym podejściu kod aplikacji po stronie serwera jest całkowicie oddzielony od kodu klienta. Aplikacja po stronie serwera odpowiedzialna jest za udostępnianie logiki biznesowej za pomocą API . Aplikacja po stronie klienta odpowiedzialna jest za pobieranie danych i obsługę interfejsu użytkownika. Oprócz oczywistego podziału funkcjonalności oba projektu istnieją jako osobne rozwiązania. Każde z rozwiązań jest wdrażane na własnej instancji serwera, jedna z nich obsługuje interfejs ASP.NET Core Web API, a druga (w zależności od wybranego przez programistę: ASP.NET lub Node) obsługuje aplikację kliencką Angular i pliki statyczne.

W odróżnieniu od podejścia all-in-one, obecnie omawiana architektura wymaga dodatkowej konfiugracji, która pozwoli na poprawne działanie projeku. W tym wypadku Microsoft nie udostępnia szablonów zapewniających konfiugrację out-of-the-box. Jako programiści musimy samodzielnie utworzyć API a następnie sparować je z aplikacją Angular po stronie klienta. Teraz dokładnie wiecie co miałem na myśli pisząc artykuł o przygotowaniu danych na potrzeby API - .NET Core: tworzenie danych na potrzeby fake API
Po utworzeniu dwóch typów aplikacji wymagane są kolejne kroki pozwalające na wzajemną komunikację pomiędzy nimi.

W pierwszym kroku wykorzystamy gotowe szablony i utworzymy nowy projekt korzystając z Visual Studio. W pierwszym kroku wybieramy ASP.NET Core Web Application: Jako, że nie potrzebujemy widoków oferowanych przez MVC wybieramy szablon API:

Potrzebujemy również aplikacji po stronie klienta. W tym celu możemy skorzystać z Angular CLI, który wygeneruje bardzo uproszczony szablon aplikacji. Wszystko jednak zależy od programisty – to on wybiera sposób tworzenia każdego z projektów. Teraz jednak nie będziemy się na tym skupiać – proces tworzenia oraz konfiguracji będzie omówiony w kolejnych artykułach, które będą pojawiać się systematycznie na blogu. Tam jednak będę opisywał preferowane przez mnie podejście w którym aplikacja po stronie sewera będzie tworzona w Visual Studio a aplikacja po stronie klienta w Visual Studio Code - po roku pracy w tym edytorze mogę powiedzieć, że idealnie nadaje się do tego zadania.

Nic jednak nie stoi na przeszkodzie, zeby projekty zostały dodane do Visual Studio. Aplikacje Angular są aplikacjami webowymi – możemy je dodać do istniejącej solucji za pomocją okna dodawania projektów: Po poprawnym dodaniu projektu możecie zobaczyć, ze obsługa każdego z nich możliwa jest w naszym środowisku programistycznym.

Praca z projektami wymaga jednak od nas dodatkowej konfiguracji. W momencie rozwoju aplikacji (programowania) aplikacja Angular oraz WebAPI będą działały na różnych portach localhost. Aby umożliwić bezproblemową współpracę aplikacji klienckiej i serwerowi należy dodać do projektu Angular plik proxy.conf.json. Pozwoli on na przygotowanie odpowiedniego mapowania a żądanie zostanie przesłane do odpowiedniej lokalizacji docelowej.

Przykładowy wpis może wyglądać w następujący sposób:

{
  "/api": {
    "target": "http://localhost:5000",
    "secure": false
  }
}

Rozdzielnie projektów pozwala na pracę nad każdym z nich niezależnie. Każdy zespół programiastów (strona klienta i serwera) może korzystać z technologii i narzędzi najlepiej pasujących do danego projektu. Aplikację po stronie serwera można zbudować przy użyciu ASP.NET Core a aplikację klienta przy użyciu Angulara, bądź jak to ma miejsce obecnie w moim przypadku, Oracle JET. Więcej informacji o tej technologii możecie znaleźć tutaj: Oracle JET

Wybór takiej architektury pozwala również na niezależne skalowanie zasobów obliczeniowych – aplikacje klienta i serwera można wdrożyć na własnych instancjach serwera.

Wybór takiej architektury może zwiększyć złożoność rozwiązania, dlatego takie podejście jest odpowiednie dla zespołów, które mają dedykowanych programistów po stronie back-end jak i front-end. Dla wielu programistów brak "narzuconej" konfiguracji to zaleta. Z kolei zaawansowane renderowanie HTML po stronie serwera będzie wymagało dodatkowej pracy.

Oprócz konfiguracji proxy w aplikacji klienckiej może być konieczne, w zależności od sposobu hostowania aplikacji, skonfigurowanie udostępniania zasobów pomiędzy źródłami w środowisku produkcyjnym CORS. W przypadku ASP.NET Core możemy skorzytać z oprogramowania pośredniczącego. Jeżeli chcesz dowiedzieć się więcej odsyłam do artykułu Enable Cross-Origin Requests (CORS) in ASP.NET Core - my zajmiemy się tym zagadnieniem nieco później.

Jak w przypadku każdego podejścia – wybieraj to, które odpowiada Twoim umiejętnością oraz kryje się ze stosem technologicznym zespołu. Może Twoim wymaganiem jest utworzenie natywnej aplikacji mobilnej? Jeżeli tak, możesz wykorzystać kolejne podejście, które omówimy w następnym artykule: wielu klientów i współdzielenie kodu.