Dlaczego duże witryny używają różnych języków jako backendu i frontendu?

Rozumiem z małych aplikacji MVC, że masz interfejs, który zajmuje się HTML, JS, jQuery itp., I masz zaplecze, które składa się z kontrolerów i modeli.

Jednak kiedy rozmawiam z programistami z dużych firm, często wspominają o posiadaniu warstwy frontendowej i warstwy backendowej. Czasami więc słyszę, że mają frontend w C # i backend w Javie. Dlaczego jakakolwiek firma chce mieć backend i frontend w różnych językach? Czy to pomaga lepiej skalować dużą witrynę?

Kiedy ludzie mówią, że ich frontend jest zbudowany w języku C #, czy to oznacza, że ​​używają frameworku dla frontendu (takiego jak .NET) i dodatkowej frameworku dla backendu (takiego jak Spring)? Czy to oznacza coś zupełnie innego?

„Front-end” i „back-end” mogą być mglistymi terminami, szczególnie w aplikacjach korporacyjnych. „Front-end” może oznaczać interfejs użytkownika lub całą aplikację. „Back-end” może oznaczać elementy wewnętrzne, lub może być wykorzystana baza danych lub usługi zewnętrzne. To, co oznaczają, często zależy całkowicie od tego, z kim rozmawiasz. Więc może zapytałeś „hej, co przez to rozumiesz?”

Kiedy zajmujesz się programowaniem w dużych przedsiębiorstwach, będziesz mieć mnóstwo zespołów piszących mnóstwo kodu. Zespoły te będą się rozwijać w różnych językach, z wykorzystaniem różnych paradygmatów, z różnych lokalizacji. Część tego kodu będzie musiała współpracować, a większość z niego nie.

Pracuję dla dużego banku. Mój zespół opracowuje naszą aplikację w języku C #. Wszystko. Ale korzystamy z usług internetowych, które są w dużej mierze napisane w Javie, i te usługi komunikują się z innymi usługami, które komunikują się z innymi usługami, które pobierają dane konta do i z odpowiednich magazynów danych i kto wie, jakie języki są z nimi używane.

Krótka wersja: ludzie używają narzędzi, które wykonują zadanie.

Myślę, że należy nieco poszerzyć pytanie: dlaczego duże projekty oprogramowania używają więcej niż jednego języka programowania?

Istnieje wiele możliwych odpowiedzi, z których najważniejsze to:

• Duże aplikacje składają się z wielu względnie niezależnych części; często każda część jest budowana przez inny zespół lub nawet innego zewnętrznego wykonawcę. Korzyść z wybrania najlepszej oferty jest często większa niż korzyść z posiadania wszystkiego w tym samym języku.
• Języki przychodzą i odchodzą, a czasem element dużego systemu przeżywa ekosystem. Przykładem ze świata Microsoftu jest to, ile firm używa teraz C # do wszystkich nowych projektów, ale wciąż mają znaczną bazę kodów VB. Koszt przepisania projektu tylko w celu wykonania go w najnowszym języku programowania jest praktycznie nigdy nieuzasadniony.
• Interfejs z komponentami innych firm. Jeśli Twój ekosystem C # musi wykonać określone zadanie, dla którego istnieją tylko rozwiązania Java, masz dwie możliwości: samodzielnie zaimplementuj rozwiązanie lub użyj rozwiązania Java i opracuj odrobinę kleju, aby zintegrować go z systemem. Ta ostatnia jest prawie zawsze tańsza w przypadku każdego nietrywialnego zadania.

Względy wydajnościowe praktycznie nigdy nie są przyczyną, z wyjątkiem aplikacji skrajnie krytycznych dla wydajności, takich jak handel z wysoką częstotliwością - w tych obszarach może być korzystne napisanie krytycznego silnika rdzenia w języku o lepszej wydajności w czasie wykonywania (powiedzmy C ++), ale systemy wspierające (interfejs użytkownika, raportowanie itp.) w czymś wyższym poziomie, takim jak Java lub C #.

Jest względny w dużym przedsiębiorstwie.
W mojej firmie stos jest z grubsza

(html/javascript)--> (JSP on Tomcat and Java based WebCMS) -> (.Net SOA)  

Tak więc dla zespołu programistów WWW frontend to HTML / JS, a backend to Java. W przypadku przedsiębiorstwa frontend to Java, a backend to .Net.

W rzeczywistości warstwa .Net musi współpracować z aplikacją COBOL / UNIX do fakturowania i roszczeń, dlatego w tej perspektywie .Net to frontend, a COBOL to backend.

I tak, jak wspomnieli inni, mamy zespoły projektantów UX, deweloperów HTML / JS, deweloperów Java, Web Middleware, deweloperów .Net, deweloperów SQL, deweloperów COBOL pracujących na każdej części stosu.

W rzeczywistości w każdym wystarczająco dużym przedsiębiorstwie są żółwie do samego końca.

Myląca semantyka

To kwestia semantyki. Kiedy ktoś mówi, że jest programistą .NET lub programistą Java, zwykle mówi o osobie, która dużo zna się na językach szablonów i może frameworkach, których nigdy nie należy używać, takich jak formularze internetowe użyte do ukrycia wyrzucanie rzeczy ponad ścianę http (tj. „tworzenie stron internetowych”) od twórców aplikacji, którzy nie chcieli lub przynajmniej nie chcieli dowiedzieć się o tym całym gównie. W przypadku mieszanych platform .NET i Java nie jestem pewien, ale mogłem tylko zgadywać, że w sensie MVC mają Java działającą dla wszystkich modeli biznesowych i .NET obsługujących wszystko inne, co byłoby lepiej opisane jako „warstwa środkowa”, ale wciąż jest po stronie serwera.

Rzeczywista separacja zachodzi na serwerze i na kliencie lub przeglądarce. Możesz łatwo połączyć budowanie kodu HTML, który ma zostać przesłany lub reprezentować interfejs użytkownika z „programowaniem frontonu”, więc wolę unikać pomyłek, używając terminów klient i serwer zamiast front i back-end podczas omawiania tego, co zwykle robię, (zwykle praca po stronie klienta).

Języki po stronie klienta

Powodem, dla którego używamy tego samego zestawu języków w przeglądarce jest to, że przeglądarka jest po stronie odbierającej i w przeważającej części (obecnie jest to prawie całkowicie martwy opór ze strony Microsoft i Adobe) nikt nie chce wysyłać trzech różne wersje tej samej strony klienta, aby zadowolić każdego potencjalnego klienta lub wymagają zainstalowania zastrzeżonej wtyczki do działania Internetu. Ponadto trzy języki naprawdę ładnie ujmują problemy po stronie klienta, co pozwala nam szybko budować i modyfikować interfejsy aplikacji internetowej, utrzymując luźne powiązanie między strukturą dokumentu, tym, jak wszystko wygląda i jak się zachowuje. Możesz zmienić jedną bez zmiany pozostałych dwóch dość łatwo.

Języki po stronie serwera

Oczywiście masz wiele bazillionów opcji po stronie serwera, ponieważ możesz. To twój serwer. Wystarczy komunikować się za pośrednictwem protokołu http / ssl, a reszta zależy od Ciebie. Nawiasem mówiąc, JavaScript jest teraz opcją, ale rodzi to interesujące pytanie. Jeśli nadal traktujesz aplikację internetową tak, jakby to naprawdę były dwie aplikacje po obu stronach tej ściany HTTP. Jestem zdania, że ​​tak, tak, powinieneś i uwielbiam Node.js.

Krótko mówiąc, jeśli masz duże projekty, masz także wiele zespołów programistów pracujących nad projektem, a te zespoły specjalizują się zwykle w różnych warstwach aplikacji.

Jeśli koncentrujesz się na interfejsie internetowym i masz swobodę wyboru sposobu implementacji, istnieje większe prawdopodobieństwo, że będziesz używać języka ukierunkowanego na interfejs WWW, takiego jak JScript lub Flex, zamiast C #.

Podobnie, jeśli jesteś na końcu aplikacji w sklepie danych transakcyjnych i masz do czynienia z wieloma równoległymi akcjami naraz, zwykle używane są wyspecjalizowane języki, takie jak erlang. (Lub produkty innych firm, które są częściowo wdrożone w tych językach)

Powodem jest równoważenie ryzyka biznesowego.

Powiedzmy, że jesteś gigantycznym pracodawcą w jednym mieście. Musisz zatrudnić wielu programistów, aby zbudować wiele różnych usług. Powiedzmy, że twoja wstępna ocena jest taka, że ​​Lanuage A najlepiej odpowiada twoim zainteresowaniom i chcesz zacząć od tego.

Jeśli zdecydujesz się na jedną technologię, możesz wyczerpać pulę talentów. Czy na pewno chcesz zatrudnić porządnego faceta Langauge A, gdy tuż za rogiem jest gwiazda języka B? Co jeśli jutro frameworki Langauge A będą wspierane przez głównego programistę? Co jeśli jutro pojawi się niesamowity Język C, powinieneś go zignorować, ponieważ pięć lat temu zobowiązałeś się do języka A?

Idealnie, czego chcesz, jest hetrogeniczny system z różnymi językami, który odzwierciedla aktualną pulę talentów i trendy technologiczne. Chcesz, aby ta równowaga powoli przesuwała się wraz ze zmianą puli talentów i trendów, tak aby w dowolnym momencie wszystkie twoje systemy były sprawne i można było zatrudnić ludzi do ich utrzymania.

... i tak robią firmy.

Przydatne jest myślenie o interfejsie i zapleczu jako osobnych aplikacjach, które korzystają z tego samego źródła danych.

Nawet w przypadku mniejszych witryn można myśleć o interfejsie jako o interfejsie klienta, a zapleczu o czymś w rodzaju CMS. Mogą to być z łatwością oddzielne aplikacje MVC. Interfejs nadal potrzebuje modeli i kontrolerów do uruchomienia - w końcu kontroler jest punktem wejścia dla odwiedzających witrynę, a modele będą sposobem, w jaki dostaniesz dane z bazy danych do użytkownika.

Zwykle lubię używać Django / Python jako CMS na zapleczu, a na froncie używam Rails, CodeIgniter lub Spring MVC. Często nie ma wyboru; klient ma już starszą witrynę skonfigurowaną w jakimś języku w interfejsie i chce tylko rozwiązania CMS. Większość klientów nawet nie wiedziałaby, że CMS działa w innym języku lub frameworku, gdyby im nie powiedziano.

Naprawdę chodzi o znalezienie tego, co najlepiej pasuje do witryny, którą chcesz zbudować. Przednie i tylne końce naprawdę muszą tylko współużytkować bazę danych, tak długo, jak oba mogą z tym pracować, możesz wybrać najlepsze opcje dla danego zadania.

Przykładem języka zaplecza jest PHP, który jest językiem skryptowym. Gdy wymagana jest strona PHP, serwer odczytuje kod PHP i renderuje znaczniki. Rezultatem jest HTML, który jest wysyłany do Ciebie. Ty, przeglądarka stron internetowych, nigdy nie widzisz jednej linii kodu PHP. Zakładając, że administrator serwera WWW poprawnie wykonał swoje zadanie, serwer będzie i nigdy nie będzie mógł pokazać ci rzeczywistego kodu PHP. Jest on analizowany, gdy strona jest wyświetlana, a wynikiem tego tłumaczenia kodu jest HTML.