Mengapa situs web besar menggunakan bahasa yang berbeda untuk backend dan frontend?

Pemahaman saya dari aplikasi MVC kecil adalah bahwa Anda memiliki ujung depan, yang berkaitan dengan HTML, JS, jQuery, dll, dan Anda memiliki ujung belakang, yang terdiri dari pengontrol dan model Anda.

Namun, ketika saya berbicara dengan pengembang dari perusahaan besar, mereka sering menyebutkan memiliki frontend tier dan backend tier. Jadi kadang-kadang, saya mungkin mendengar bahwa mereka memiliki frontend dengan C # dan backend dengan Java. Mengapa ada perusahaan yang menginginkan backend dan frontend dalam berbagai bahasa? Apakah ini membantu skala situs web besar lebih baik?

Ketika orang mengatakan bahwa frontend mereka dibangun dalam C #, apakah ini berarti bahwa mereka menggunakan kerangka kerja untuk frontend (seperti .NET) dan kerangka kerja tambahan di backend (seperti Spring)? Atau apakah itu berarti sesuatu yang sama sekali berbeda?

"Front-end" dan "Back-end" dapat menjadi istilah yang samar-samar, terutama dalam aplikasi perusahaan. "Front-end" dapat berarti UI, atau bisa juga seluruh aplikasi. "Back-end" dapat digunakan untuk maksud internal, atau bisa juga database atau layanan eksternal yang dikonsumsi. Apa yang dimaksud dengan istilah-istilah tersebut seringkali bergantung sepenuhnya kepada siapa Anda berbicara. Jadi, apakah Anda mungkin bertanya, "Hei, apa yang Anda maksud dengan itu?"

Ketika Anda masuk ke pengembangan perusahaan besar, Anda akan memiliki banyak dan banyak tim menulis banyak dan banyak kode. Tim-tim ini akan berkembang dalam berbagai bahasa, menggunakan paradigma yang berbeda, dari lokasi yang berbeda. Beberapa kode ini perlu bekerja bersama dan sebagian besar tidak.

Saya bekerja untuk bank besar. Tim saya mengembangkan aplikasi kami di C #. Semua itu. Tetapi kami menggunakan layanan web yang sebagian besar ditulis di Jawa, dan layanan tersebut berbicara dengan layanan lain yang berbicara dengan layanan lain yang mendapatkan data akun ke dan dari penyimpanan data yang sesuai, dan siapa yang tahu bahasa apa yang digunakan dengan layanan tersebut.

Versi singkat: Orang menggunakan alat yang menyelesaikan pekerjaan.

Saya pikir Anda perlu sedikit memperluas pertanyaan: Mengapa proyek perangkat lunak besar menggunakan lebih dari satu bahasa pemrograman?

Ada banyak kemungkinan jawaban, yang paling penting adalah:

• Aplikasi besar terdiri dari banyak bagian yang relatif independen; seringkali, setiap bagian dibangun oleh tim yang berbeda atau bahkan kontraktor eksternal yang berbeda. Manfaat memilih tawaran terbaik seringkali lebih besar daripada manfaat memiliki segalanya dalam bahasa yang sama.
• Bahasa datang dan pergi, dan kadang-kadang komponen dari sistem besar hidup lebih lama dari ekosistem. Contoh dari dunia Microsoft adalah berapa banyak perusahaan sekarang menggunakan C # untuk semua proyek baru, tetapi mereka masih memiliki basis kode VB yang cukup besar. Biaya penulisan ulang proyek hanya untuk melakukannya dalam bahasa pemrograman terbaru praktis tidak pernah dibenarkan.
• Berinteraksi dengan komponen pihak ketiga. Jika ekosistem C # Anda perlu melakukan tugas tertentu yang hanya ada solusi Java, maka Anda memiliki dua pilihan: mengimplementasikan solusi sendiri, atau menggunakan solusi Java dan mengembangkan sedikit lem untuk mengintegrasikannya ke dalam sistem Anda. Yang terakhir ini hampir selalu lebih murah untuk tugas non-sepele.

Pertimbangan kinerja praktis tidak pernah menjadi alasan, kecuali dalam aplikasi yang sangat kritis terhadap kinerja seperti perdagangan frekuensi tinggi - di area tersebut, dapat bermanfaat untuk menulis mesin inti kritis dalam bahasa dengan kinerja run-time yang lebih baik (katakanlah, C ++), tetapi sistem pendukung (UI, pelaporan, dll.) di tingkat yang lebih tinggi seperti Java atau C #.

Itu relatif dalam perusahaan besar.
Di perusahaan saya tumpukannya kira-kira

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

Jadi untuk tim pengembangan web frontend adalah HTML / JS dan backend adalah Java. Untuk perusahaan frontend adalah Java dan backend adalah .Net.

Sebenarnya layer .Net harus bekerja dengan aplikasi COBOL / UNIX untuk Penagihan dan Klaim dan dalam perspektif ini .Net adalah frontend dan COBOL adalah backend.

Dan ya seperti yang disebutkan orang lain, kami memiliki tim desainer UX, pengembang HTML / JS, pengembang Java, Web Middleware,. Pengembang internet, pengembang SQL, pengembang COBOL yang bekerja di setiap bagian stack.

Faktanya, di perusahaan besar mana pun, itu adalah kura-kura.

Semantik yang membingungkan

Ini masalah semantik. Ketika seseorang mengatakan .NET front end atau Java front end developer, mereka biasanya berbicara tentang orang yang tahu banyak tentang bahasa templating dan mungkin kerangka kerja yang seharusnya tidak pernah digunakan lagi seperti formulir web yang digunakan untuk mencoba dan menyembunyikan membuang hal-hal melalui dinding http (yaitu "pengembangan web") dari pengembang aplikasi yang tidak mau atau setidaknya dianggap tidak ingin mempelajari semua omong kosong itu. Dalam kasus campuran .NET dan Java, saya tidak yakin tetapi saya hanya bisa menebak bahwa dalam pengertian MVC hal-hal yang mereka punya Java bertindak untuk semua hal model bisnis dan. NET menangani segala hal lain yang akan lebih baik dijelaskan sebagai "tingkat menengah" tetapi masih semua sisi server.

Pemisahan yang sebenarnya adalah apa yang terjadi di server dan apa yang terjadi pada klien atau browser. Anda dapat dengan mudah mengacaukan pembuatan HTML untuk dikirim ke atau mewakili ujung depan dengan "pengembangan ujung depan" jadi saya lebih suka menghindari kebingungan dengan menggunakan istilah klien dan sisi server daripada sisi depan dan belakang saat membahas apa yang biasanya saya lakukan, (biasanya pekerjaan sisi klien).

Bahasa Sisi Klien

Alasan kami menggunakan kumpulan bahasa yang sama di browser adalah karena browser berada di pihak penerima dan sebagian besar (sekarang ada sebagian besar perlawanan mati dari Microsoft dan Adobe dalam hal ini) tidak ada yang mau harus mengirim tiga versi berbeda dari sisi klien yang sama untuk memuaskan setiap pelanggan potensial atau mengharuskan plug-in eksklusif dipasang agar web dapat berfungsi. Selain itu, ketiga bahasa tersebut sebenarnya merangkum masalah sisi klien dengan cukup baik, memungkinkan kami untuk dengan cepat membangun dan memodifikasi ujung depan aplikasi web dengan mempertahankan sambungan longgar antara struktur dokumen, bagaimana segala sesuatu terlihat dan bagaimana semua itu berperilaku. Anda dapat mengubah satu tanpa mengubah dua lainnya dengan cukup mudah.

Bahasa Sisi Server

Alasan Anda memiliki banyak pilihan di sisi server tentu saja karena Anda bisa. Ini server Anda. Yang harus dilakukan adalah berkomunikasi melalui http / ssl dan sisanya terserah Anda. JavaScript sekarang menjadi pilihan, tetapi memunculkan pertanyaan yang menarik. Jika Anda masih memperlakukan aplikasi web seperti itu benar-benar dua aplikasi di kedua sisi dinding HTTP itu. Saya memiliki opini yang sangat mendalam bahwa ya, ya Anda harus dan saya suka Node.js.

Singkatnya, di mana Anda memiliki proyek besar, Anda juga memiliki beberapa tim pengembang yang mengerjakan proyek, dan tim tersebut cenderung berspesialisasi pada lapisan aplikasi yang berbeda.

Jika Anda berfokus pada UI web, dan Anda memiliki fleksibilitas dalam pilihan implementasi Anda, Anda akan lebih cenderung menggunakan bahasa yang ditargetkan untuk web ui, seperti JScript atau Flex, daripada C #.

Demikian juga, jika Anda berada di akhir penyimpanan data aplikasi transaksional, berurusan dengan banyak tindakan bersamaan, bahasa khusus seperti erlang cenderung digunakan. (Atau produk pihak ketiga yang diterapkan sebagian dalam bahasa ini)

Alasannya adalah penyeimbangan risiko bisnis.

Katakanlah Anda adalah majikan raksasa di satu kota. Anda harus mempekerjakan banyak pengembang untuk membangun banyak layanan yang berbeda. Katakanlah evaluasi awal Anda adalah bahwa Lanuage A paling sesuai dengan minat Anda, dan Anda ingin memulainya.

Jika Anda berkomitmen pada satu teknologi, Anda bisa mengeringkan talenta. Apakah Anda yakin ingin mempekerjakan seorang Langauge yang baik ketika ada bintang Bahasa B di ujung jalan? Bagaimana jika besok kerangka kerja Langauge A didukung oleh pengembang utama? Bagaimana jika besok ada Bahasa C yang luar biasa, haruskah Anda mengabaikannya karena Anda berkomitmen pada bahasa A lima tahun lalu?

Idealnya yang Anda inginkan adalah sistem heterogen dengan berbagai bahasa yang mencerminkan kumpulan bakat dan tren teknologi saat ini. Anda ingin keseimbangan ini bergeser perlahan karena kumpulan bakat dan tren berubah sehingga pada semua titik semua sistem Anda bisa diterapkan dan Anda dapat mempekerjakan orang untuk mempertahankannya.

... dan itulah yang dilakukan perusahaan.

Sangat membantu untuk memikirkan ujung depan dan ujung belakang Anda sebagai aplikasi terpisah yang keduanya menggunakan sumber data yang sama.

Bahkan untuk situs yang lebih kecil, Anda dapat menganggap ujung depan sebagai antarmuka klien, dan ujung belakang sebagai sesuatu seperti CMS. Ini dapat dengan mudah menjadi aplikasi MVC yang terpisah. Ujung depan masih memerlukan model dan pengontrol untuk berjalan - setelah semua, pengontrol adalah titik masuk bagi pengunjung situs Anda dan model akan menjadi cara Anda mendapatkan data dari database Anda ke pengguna.

Saya cenderung suka menggunakan Django / Python sebagai CMS di ujung belakang, dan menggunakan Rails, CodeIgniter atau Spring MVC di ujung depan. Seringkali tidak ada pilihan; klien sudah memiliki beberapa situs warisan yang diatur dalam beberapa bahasa di ujung depan dan mereka hanya menginginkan solusi CMS. Sebagian besar klien bahkan tidak akan tahu CMS menjalankan bahasa atau kerangka kerja yang berbeda jika mereka tidak diberi tahu.

Ini benar-benar tentang menemukan yang terbaik untuk situs yang ingin Anda buat. Ujung depan dan belakang benar-benar hanya perlu berbagi database, sehingga selama keduanya dapat bekerja dengan itu, jangan ragu untuk memilih opsi terbaik untuk tugas yang ada.

Contoh bahasa back end adalah PHP, yang merupakan bahasa scripting. Ketika halaman PHP diminta, server membaca kode PHP dan merender markup. Hasilnya adalah HTML yang dikirimkan kepada Anda. Anda, penampil halaman web, tidak pernah melihat satu baris kode PHP. Dengan asumsi bahwa administrator server web telah melakukan tugasnya dengan benar, server akan, dan tidak pernah dapat menunjukkan kepada Anda kode PHP yang sebenarnya. Itu diuraikan ketika halaman disajikan dan hasil terjemahan kode adalah HTML.