docker - realne zastosowanie

Na wstępie napiszę - tak szukałem i czytałem w sieci artykuły, ale dalej nie rozumiem do czego Docker może być przydatny jak mamy aplikację napisaną, np. w ASP. NET MVC, która musi stać na windowsie.
W artykułach były opisane aplikacje napisane w php, gdzie trzeba zainstalować apache, mysql itd. - to na Dockerze to można zainstalować to to rozumiem. A aplikacja ASP.NET MVC?

Na prawdę wpisanie w google 'docker .net core' było takie trudne?
https://docs.docker.com/engine/examples/dotnetcore/

EDIT
Poza tym, mimo że masz aplikacje w .net'cie często korzystasz w niej z jakiejś bazy. U nas w firmie dzięki dockerowi każdy zaoszczędzą co najmniej parę godzin gdy trzeba w środowisku dev użyć danych z redisa z danymi produkcyjnymi. Normalnie trwało by parę godzin zanim wszystko by się ogarnęło, a tak to tylko docker-compose up i w pół minuty wszystko zrobione.

EDIT2:
Przepraszam, pomyliłem .net z ASP.net mvc. Tu link do i strukcji z drugim https://docs.microsoft.com/pl-pl/aspnet/mvc/overview/deployment/docker-aspnetmvc

Czyli używacie Dockera w sytuacji, gdy na produkcji jest jakiś błąd i chcecie odtworzyć tę sytuację lokalnie przy użyciu bazy produkcyjnej - no, ok możecie się wówczas szybko przełączyć między bazami. Dziękuję.

A jeszcze jakieś inne zastosowania? Ten artykuł nie jest zbyt konkretny:
Open-source
Develop and run your ASP.NET Core apps cross-platform on Windows, MacOS, and Linux
Great for modern cloud-based apps, such as web apps, IoT apps, and mobile backends
ASP.NET Core apps can run on .NET Core or on the full .NET Framework
Designed to provide an optimized development framework for apps that are deployed to the cloud or run on-premises
Modular components with minimal overhead retain flexibility while constructing your solutions

Już nawet nieważne czy aplikacja jest w .NET Core czy .NET Framework. Załóżmy, że 5 deweloperów rozwija jakąś aplikację - jak Doker może im ułatwić pracę?

Z tego co widziałem to Docker bardzo by się przydał gdybyśmy mieli aplikacje w różnych technologiach: wówczas w jednym kontenerze mielibyśmy php/apache/mysql, w drugim java/linux w trzecim c#/windows. Czyli jeden mikroserwis w jednej technologii byłby w jednym kontenerze, drugi w drugiej technologii w drugim kontenerze, a trzeci w trzeciej technologii w trzecim kontenerze. Deweloperzy nie musieliby instalować u siebie php, apache, linuxa itd. - ale jak wszystkie mikroserwisy sa w dokładnie tej samej technologii - c# i każdy deweloper i tak ma zainstalowanego u siebie na komputerze windowsa, .NETa itd. to jaka to zaleta?

Główną zaletą dockera jest jego izolacja. Cały stack aplikacji możesz przenosić pomiędzy środowiskami poprzez tak naprawdę jeden plik - docker-compose. Masz wtedy wyizolowaną aplikacje, która na
każdym środowisku stawia się bardzo szybko oraz zachowuje tak samo.

Jeżeli nie widzisz / nie ma dla ciebie zalet, to go nie używaj, bo dodajesz sobie kolejny point of failure albo po prostu stracisz dużo czasu, a zyskasz niewiele.

Ogólnie jest to wygodna zabawka do testów, gdy trzeba postawić coś jak najszybciej się da, a nie tracić 2h na instalowanie czegoś na VMce albo u siebie.

Jeżeli coś wrzuca się na siłę, bo "wszyscy tak robią" to od razu można iść po Hype-Quadro-Stack: Mongo+Node+Docker+Blockchain :D

Moze tez chodzic o optymalizacje kosztow systemu VM. Np. moze sie okazaz ze taniej wyjdzie jedna duza maszyna niz dwie male, chociaz patrzac na ceny AWS nie widze by tak faktycznie bylo. Ale za to mozna "dopelnic maszyne".

Czyli mamy server ktory potrzebuje 1.2 m5.xlarge i drugi ktory potrzebuje 0.6 m5.xlarge wtedy zamiast brac m5.2xlarge i m5.xlarge zmiescimy system na jednym m5.2xlarge (upraszczam, bo w rzeczywistosci te wyliczenie nie sa takie proste, zwlaszcza ograniczenie bandwith dla sieci jest zdradliwe na AWS).

No właśnie chciałbym Dockera bardzo użyć u siebie w firmie, ale 'muszę' znaleźć jakieś sensowne jego zastosowanie do tworzonego projektu, a nie tylko ze względu na to, że jest modny.

Docker jest fajny jeżeli masz kilka różnych apek z różnymi wymaganiami i w różnych wersjach i próbujesz to wszystko uruchamiać na jednym serwerze. Wszystko jest spoko jak zainstalujesz i dopieścisz to na początku, ale potem nagle przychodzi ci zrobić upgrade jednej z nich (przykładowo .NET Core 2.1 > 2.2). Okazuje się, że trzeba zainstalować .NET Core 2.2, ale do niego potrzebna jest jakaś biblioteka w wersji, której nie znajdziesz w danym systemie lub jej wersja kłóci się z wersją dla innej apki. Jesteś w d..... Ale jeżeli użyjesz dockera to tylko podmienisz obraz źródłowy na taki obsługujący 2.2 i ogień.
Poza tym cała koncepcja orkiestracji (nienawidzę tego słowa) za pomocą docker-compose jest bardzo przydatna w utrzymaniu. Jeżeli masz system jak wyżej to w razie grzebania i położenia jednej lub wielu apek masz zabawę, żeby to odtworzyć do stanu pierwotnego, a jeżeli wszystko przygotowałeś sobie wcześniej w formie plików .yml to odtwarzasz tylko dane, puszczasz doker-compose up i idziesz na kawę.
Do tego oczywiście dochodzi możliwość w 100% odtworzenia środowiska testowego na produkcji.

Mały napisał(a):

Docker jest fajny jeżeli masz kilka różnych apek z różnymi wymaganiami i w różnych wersjach i próbujesz to wszystko uruchamiać na jednym serwerze. Wszystko jest spoko jak zainstalujesz i dopieścisz to na początku, ale potem nagle przychodzi ci zrobić upgrade jednej z nich (przykładowo .NET Core 2.1 > 2.2). Okazuje się, że trzeba zainstalować .NET Core 2.2, ale do niego potrzebna jest jakaś biblioteka w wersji, której nie znajdziesz w danym systemie lub jej wersja kłóci się z wersją dla innej apki. Jesteś w d..... Ale jeżeli użyjesz dockera to tylko podmienisz obraz źródłowy na taki obsługujący 2.2 i ogień.
Poza tym cała koncepcja orkiestracji (nienawidzę tego słowa) za pomocą docker-compose jest bardzo przydatna w utrzymaniu. Jeżeli masz system jak wyżej to w razie grzebania i położenia jednej lub wielu apek masz zabawę, żeby to odtworzyć do stanu pierwotnego, a jeżeli wszystko przygotowałeś sobie wcześniej w formie plików .yml to odtwarzasz tylko dane, puszczasz doker-compose up i idziesz na kawę.
Do tego oczywiście dochodzi możliwość w 100% odtworzenia środowiska testowego na produkcji.

O dziękuję :)

Np.Aplikacja mikroserwisowa - każdy mikroserwis to osobna aplikacja - postawiona w osobnym kontenerze. Jeśli dany element systemu trzeba skalować bo ulego większemu obciążeniu to odpalamy kolejne kontenery z tą apką
Środowisko developerskie - ile razy konfigurowałęś nowy projekt przez ponad pół dnia ? Docker compose umozliwia odpalenia całego środowiska (np. API + Frontend + baza+jakiś redis) w zasadzie jedną komendą. Docker sam pobierze zależności i je odpali. To szczególnie fajne dla Frontendu - nie muszą pół dnia stawiać backendiu żeby testować calle u siebie - docker-compose up i lecimy.

Ważna uwaga - bo to może być mylące na początku. Kontener można traktować jako osobną maszynę wirtualną - ALE powinien on mieć w sobie tylko jedną główną aplikację - nie tworzy się kontenerów w stylu (mssql+api+coś tam). Każda aplikacja to zawsze osobny kontener. Teoretycznie można odpalić kilka aplikacji na raz - to w końcu linux - ale nie po to było to projektowane. Jesli odpalone jest kilka alikacji główny to jeśli jedna się sypnie to nie wiadomo co zrobić - jeśli jest jedna to kontener jest ubijany. Zwróć też uwagę na rożnicę między kontenerem a obrazem.

W2K napisał(a):

Np.Aplikacja mikroserwisowa - każdy mikroserwis to osobna aplikacja - postawiona w osobnym kontenerze. Jeśli dany element systemu trzeba skalować bo ulego większemu obciążeniu to odpalamy kolejne kontenery z tą apką

A gdzie konkretnie je odpalamy? Bo jak w chmurze, to te serwisy same się skalują.

Środowisko developerskie - ile razy konfigurowałęś nowy projekt przez ponad pół dnia ?

Pół dnia? Luksus! Ja jakieś 3-5 lat temu mieszkałem w pudełku po butach... trafiałem do projektów, które odpalało się na swojej maszynie 3-5 dni.
Ile by to trwało z dockerem? Stawiam, że jakieś dwa tygodnie. Bo to byłby specjalny, zaprojektowany przez najlepszych korporacyjnych architektów docker, który działa tylko na maszynach VMWare z zainstalowaną Mandrivą 10, pod warunkiem, że serwer fizyczny ma dostępną stację dyskietek 5,25" oraz na stałe zwarte styki 2 i 6 w porcie COM2. Do tego docker-compose zapewne daliby radę zamienić jakimś znacznie bardziej zaawansowanym i potężnym rozwiązaniem bazującym na dużej ilości plików bat i xml. (Wiadomo - XML jest jak przemoc. Jeśli nie rozwiązuje Twoich problemów, to znaczy, że używasz go za mało.)
To jest kwestia bardziej podejścia i organizacji, narzędzi w mniejszym stopniu. Oczywiście dobre narzędzia użyte odpowiednio z przeznaczeniem pomogą w wielu sytuacjach. Ale można też do tych sytuacji nie doprowadzać.

To szczególnie fajne dla Frontendu - nie muszą pół dnia stawiać backendiu żeby testować calle u siebie - docker-compose up i lecimy.

A nie można po prostu wysyłać requestów do jakiegoś backendu na środowisku testowym?

Mandrivą 10.

Płakałem...

somekind napisał(a):

Ile by to trwało z dockerem? Stawiam, że jakieś dwa tygodnie. Bo to byłby specjalny, zaprojektowany przez najlepszych korporacyjnych architektów docker, który działa tylko na maszynach VMWare z zainstalowaną Mandrivą 10, pod warunkiem, że serwer fizyczny ma dostępną stację dyskietek 5,25" oraz na stałe zwarte styki 2 i 6 w porcie COM2.

Żadne z tych wymagań nie jest podyktowane Dockerem - jeśli ktoś zaprojektował aplikację w taki sposób, że przed odpaleniem trzeba recytować na stojąco Tuwima, no to sry - Docker niewiele pomoże.

Warto jednak zauważyć, że - o ile nie jest stosowany bezmyślnie - też nie zaszkodzi, a przynajmniej nie w taki przerysowany sposób, w jaki to próbujesz zobrazować.

Ideologicznie do wystartowania projektu od zera powinno wystarczyć ustawienie kluczy SSH, docker-compose up / lxc launch i wsio; fakt, że ktoś może źle zaprojektować kontener nie ma nic wspólnego z samą technologią, ponieważ równie dobrze ta sama osoba może np. źle przygotować migracje bazy danych i odpalenie od zera Postgresa będzie wymagało przebrnięcia przez dziesięć skryptów bashowych, trzy batche, odpalenie czegoś przez Wine i pobranie połowicznego dumpa danych z produkcji ("no bo jakoś tak wyszło, że mamy rozjazd między migracjami a produkcją - ja tam się nie do końca na tym znam").

Nie przedstawiłeś IMO nic sensownego w kontekście samego Dockera - ot: źle stosowane technologie są źle stosowane i tyle.

A nie można po prostu wysyłać requestów do jakiegoś backendu na środowisku testowym?

I tak, i nie - jeśli pracujesz razem z frontendowcem nad nowym zadaniem i nie chcesz aby wysyłał żądania na Twój komputer (ponieważ co chwilę zmieniasz kod), kontenery są stosunkowo prostym rozwiązaniem. Instalujesz taki kontener u frontendowca, robisz checkouta na ostatnim stabilnym commicie ze wspólnego brancha i niech sobie robi co dusza zapragnie.

Patryk27 napisał(a):

Żadne z tych wymagań nie jest podyktowane Dockerem - jeśli ktoś zaprojektował aplikację w taki sposób, że przed odpaleniem trzeba recytować na stojąco Tuwima, no to sry - Docker niewiele pomoże.

Warto jednak zauważyć, że - o ile nie jest stosowany bezmyślnie - też nie zaszkodzi, a przynajmniej nie w taki przerysowany sposób, w jaki to próbujesz zobrazować.

Ja nie pisałem, że docker zaszkodzi ani, że ma takie wymagania. Ja pisałem, że jeśli ktoś dopuścił do wielogodzinnego i skomplikowanego stawiania środowiska bez dockera, to czemu miałby nie dopuścić do tego z dockerem? Jak ktoś jest brudasem, to przeprowadzka z chlewu do pałacu nie pomoże. Jeśli ktoś jest bezmyślny, to dockera też będzie używał bezmyślnie.

Ideologicznie do wystartowania projektu od zera powinno wystarczyć ustawienie kluczy SSH, docker-compose up / lxc launch i wsio; fakt, że ktoś może źle zaprojektować kontener nie ma nic wspólnego z samą technologią, ponieważ równie dobrze ta sama osoba może np. źle przygotować migracje bazy danych i odpalenie od zera Postgresa będzie wymagało przebrnięcia przez dziesięć skryptów bashowych, trzy batche, odpalenie czegoś przez Wine i pobranie połowicznego dumpa danych z produkcji ("no bo jakoś tak wyszło, że mamy rozjazd między migracjami a produkcją - ja tam się nie do końca na tym znam").

Dokładnie o to mi chodzi!

Nie przedstawiłeś IMO nic sensownego w kontekście samego Dockera - ot: źle stosowane technologie są źle stosowane i tyle.

Ale ja nie miałem zamiaru argumentować przeciwko dockerowi, tylko przeciwko takiemu hurraoptymistycznemu podejściu, jakoby on sam magicznie coś sprawiał, i był jedynym rozwiązaniem dla długiej konfiguracji środowiska pracy.

I tak, i nie - jeśli pracujesz razem z frontendowcem nad nowym zadaniem i nie chcesz aby wysyłał żądania na Twój komputer (ponieważ co chwilę zmieniasz kod), kontenery są stosunkowo prostym rozwiązaniem. Instalujesz taki kontener u frontendowca, robisz checkouta na ostatnim stabilnym commicie ze wspólnego brancha i niech sobie robi co dusza zapragnie.

No na pewno bym nie chciał, żeby wysyłał na mój komputer, dlatego właśnie stabilna wersja backendu powinna być na serwerze testowym.

Ale ja nie miałem zamiaru argumentować przeciwko dockerowi, tylko przeciwko takiemu hurraoptymistycznemu podejściu, jakoby on sam magicznie coś sprawiał, i był jedynym rozwiązaniem dla długiej konfiguracji środowiska pracy.

Ano ok, w takim razie nie zrozumiałem intencji ;-)

No na pewno bym nie chciał, żeby wysyłał na mój komputer, dlatego właśnie stabilna wersja backendu powinna być na serwerze testowym.

Co w sytuacji, gdy jednocześnie masz kilka osobnnych zadań w drodze (zarówno frontendowych, jak i backendowych, jak i frontendowo-backendowych)?
Do którego brancha powinni bić frontendowcy pracujący w parze z backendowcami nad nowymi zadaniami?

Patryk27 napisał(a):

Co w sytuacji, gdy jednocześnie masz kilka osobnnych zadań w drodze (zarówno frontendowych, jak i backendowych, jak i frontendowo-backendowych)?

Ale co to jest zadanie frontendowo-backendowe? Żeby frontend mógł coś zrobić, najpierw backend musi to umożliwić. Potrzebne są dwa zadania. Najpierw robimy backend, testujemy go, potem frontendowcy mogą się zająć swoją robotą współpracując ze stabilnym backendem na serwerze testowym.

Najpierw robimy backend, testujemy go, potem frontendowcy mogą się zająć swoją robotą współpracując ze stabilnym backendem na serwerze testowym.

W idealnym świecie może i tak. W rzeczywistości często można spotkać się z sytuacją, którą można by krótko opisać: Daj mi cokolwiek, co mniej więcej działa, żebym mógł zacząć prace nad moją częścią. Powodem może być deadline, ale też np. sytuacja, w której frontendowiec nie ma nic innego do roboty i już chciałby ruszać właśnie z tym.

To by znaczyło, że frontend jest obrobiony z taskami przed backendem, co jest mało możliwe.
Ale jak tak bardzo chce pracować, to ja nie bardzo rozumiem w czym problem. Niech sobie frontend jakieś fejkowe dane zahardcoduje po prostu.

Ja lubię w dockerze dwie rzeczy: izolację i odtwarzalność.
Izolacja jest spoko, mogę mieć w każdym kontenerze zupełnie inne środowisko i ciągle mogę to odpalić na jednym i tym samym systemie, nie muszę przejmować się niekompatybilnymi wersjami i zależnościami, a ni tym, że aktualizując paczkę dla aplikacji A zepsuję aplikację B.

Odtwarzalność jest świetna, bo mogę bez obaw grzebać w konfiguracjach, paczkach, ustawieniach, wersjach, a jak coś zepsuję, to cofam zmiany gitem i po problemie. To dotyczy też wszystkich zależności i aplikacji dookoła. Ponadto przy wdrażaniu na różne środowiska wiem, że mam ten sam stan, niezależnie od hosta.

somekind napisał(a):

To by znaczyło, że frontend jest obrobiony z taskami przed backendem, co jest mało możliwe.
Żeby frontend mógł coś zrobić, najpierw backend musi to umożliwić.

Macie jakąś dziwną organizację, frontend spokojnie może pracować bez backendu.

Afish napisał(a):

Macie jakąś dziwną organizację, frontend spokojnie może pracować bez backendu.

I czyta dane z bazy, wysyła przelewy do banków, a klientom towar bezpośrednio?
To taki frontend chyba też jest backendem.

Nie, frontend robi to, co do niego należy, a robotę backendową zostawia backendowi.

Do frontendu należy wyświetlenie danych z backendu oraz umożliwienie użytkownikowi przeprowadzenia transakcji na backendzie. U nas frontend bez backendu może się co najwyżej załadować i wyświetlić komunikat o braku łączności. To nie jest kwestia dziwnej organizacji tylko typowego biznesu.

somekind napisał(a):

To nie jest kwestia dziwnej organizacji tylko typowego biznesu.

Najwyraźniej po prostu nie umiecie klepać frontendu bez gotowego backendu, ale to nie znaczy, że jest to „typowy biznses”. Pracowałem z wieloma aplikacjami SPA i nie-SPA, gdzie brak gotowego backendu nie był problemem dla frontendowców i jakoś potrafili wyklepać wszystko, zanim ja w ogóle wziąłem się do pracy.

Afish napisał(a):

Najwyraźniej po prostu nie umiecie klepać frontendu bez gotowego backendu, ale to nie znaczy, że jest to „typowy biznses”.

Skoro interpretujesz swoje imaginacje, to nie mam jak się nie zgodzić.

Pracowałem z wieloma aplikacjami SPA i nie-SPA, gdzie brak gotowego backendu nie był problemem dla frontendowców i jakoś potrafili wyklepać wszystko, zanim ja w ogóle wziąłem się do pracy.

I ten naklepany frontend realizował procesy biznesowe sam, bez udziału backendu? Jeśli tak, to backend nigdy nie był potrzebny, jeśli nie, to jakby nie ma powodu do chwały.

Jeśli backend nie umożliwia czegoś, to frontend choćby się nie wiem jak starał, nie dostarczy tego ficzera użytkownikowi.

A programiści klepać sobie można w dowolnej kolejności, nigdzie nie pisałem, że frontendowcy nie mogą zacząć przed backendowcami. Nawet napisałem, że jak frontendowcy chcą zacząć przed backendowcami, to ich odpowiedzialnością jest zamockowanie sobie tego, czego backend nie dostarcza.

somekind napisał(a):

Skoro interpretujesz swoje urojenia, to nie mam jak się nie zgodzić.
I ten naklepany frontend realizował procesy biznesowe sam, bez udziału backendu? Jeśli tak, to backend nigdy nie był potrzebny, jeśli nie, to jakby nie ma powodu do chwały.

Najpierw zarzucasz mi urojenia, potem znajdujesz nieistniejące stwierdzenia, a potem bohatersko z nimi walczysz? Jak nie chce Ci się prowadzić dyskusji na poziomie, to może lepiej przestań.

Jeśli backend nie umożliwia czegoś, to frontend choćby się nie wiem jak starał, nie dostarczy tego ficzera użytkownikowi.

Tak.

A programiści klepać sobie można w dowolnej kolejności, nigdzie nie pisałem, że frontendowcy nie mogą zacząć przed backendowcami.

Też tak nie napisałem.

Afish napisał(a):

Najpierw zarzucasz mi urojenia, potem znajdujesz nieistniejące stwierdzenia, a potem bohatersko z nimi walczysz?

Nie znalazłem żadnego nieistniejącego stwierdzenia, rozpatrzyłem dwie alternatywy jednej tezy.

Jak nie chce Ci się prowadzić dyskusji na poziomie, to może lepiej przestań.

Napisałem, że backend musi dostarczyć ficzer, zanim frontend go udostępni użytkownikowi. Ty z tego wyciągnąłeś wniosek, że "nie umiemy". Mam rozumieć, że dla Ciebie to jest dyskusja na poziomie? :)

Nigdzie nie pisałem, że można wystawić do użytkownika frontend bez gotowego backendu, nie wiem, dlaczego o czymś takim pomyślałeś. Napisałem, że backendowcy nie muszą skończyć swojej pracy przed frontendowcami. Nawet mogę przytoczyć to, do czego się odnosiłem:

somekind napisał(a):

To by znaczyło, że frontend jest obrobiony z taskami przed backendem, co jest mało możliwe.
Żeby frontend mógł coś zrobić, najpierw backend musi to umożliwić.

Nie uważam, że „jest mało możliwe”, aby frontend był „obrobiony z taskami przed backendem”, widziałem to w pracy wielokrotnie. To nie znaczy, że jak wyklepie się skrypty i style, to od razu pcha się to do klienta…

somekind napisał(a):

Napisałem, że backend musi dostarczyć ficzer, zanim frontend go udostępni użytkownikowi. Ty z tego wyciągnąłeś wniosek, że "nie umiemy". Mam rozumieć, że dla Ciebie to jest dyskusja na poziomie? :)

Kto powiedział, że od razu po zaklepaniu fronta wszystko leci do usera?

Nie wszędzie potrzebujesz backend aby wyświetlać dane i te miejsca można spokojnie zrobić bez backendu, ale gorzej jeżeli modele będą się 15 razy zmieniać.

Ba, możesz nawet sobie wystawić Fake-Backend, który będzie zwracał coś, co w przyszłości tam będzie i nikt niczego nie blokuje. Pytanie tylko czy się opłaca czasowo w to bawić.

Afish napisał(a):

Nigdzie nie pisałem, że można wystawić do użytkownika frontend bez gotowego backendu, nie wiem, dlaczego o czymś takim pomyślałeś.

Tak zinterpretowałem Twoje zdanie:

Macie jakąś dziwną organizację, frontend spokojnie może pracować bez backendu.

Widocznie niepoprawnie (bo i od początku to nie miało sensu), dlatego później dopytywałem (a nie zarzucałem). Wyraziłeś się nieprecyzyjnie, bo napisałeś frontend i backend, zamiast frontendowcy i backendowcy. Przy czym ja to zrobiłem pierwszy, więc biję się w pierś, bo najwyraźniej ja jestem inicjatorem całego nieporozumienia, przepraszam.

Nie uważam, że „jest mało możliwe”, aby frontend był „obrobiony z taskami przed backendem”, widziałem to w pracy wielokrotnie.

Nie kłócę się, to kwestia mocno subiektywna. Ty masz inne doświadczenia, ja raczej jestem przyzwyczajony do tego, że to raczej frontendowcy mają problemy z dotrzymaniem terminów, a taski frontendowe częściej mają tendencje do powstawania w nich nieprzewidzianych problemów.
No i od razu napisałem, jak można rozwiązać problem z brakiem backendu do powstającego frontendu.

Oczywiście, można hardkodować. Ale można też postawić dockera ;)
Docker będzie lepszym rozwiązaniem tam, gdzie praca jest bardziej "dynamiczna", a założenia są uściślane w trakcie pracy. Niestety mam z tym do czynienia dość często. Rozmowy w stylu:

• Ej, a jak mam niby wyświetlić to, bez tamtego?
• Ano fakt, czekaj, to zaraz dorobię
• Dlaczego przestało działać to a tamto?
• Aaa bo tu się nazwa parametru zmieniła

Poza tym, frontend nie tylko wyświetla dane z backendu, ale czasem też coś do backendu wysyła. Oprogramowując wysyłanie danych muszę uwzględnić też sytuacje błędne (czyli np. api nie odpowiada; i w sumie przy wyświetlaniu też). Jak się uprzeć, to też można to hardkodować. Mi jednak wygodniej pracować z prawdziwym systemem.