Tại sao các trang web lớn sử dụng các ngôn ngữ khác nhau cho phụ trợ và frontend?

Sự hiểu biết của tôi từ các ứng dụng MVC nhỏ là bạn có giao diện người dùng, giao dịch với HTML, JS, jQuery, v.v. và bạn có mặt sau, bao gồm các bộ điều khiển và mô hình của bạn.

Tuy nhiên, khi tôi nói chuyện với các nhà phát triển từ các công ty lớn, họ thường đề cập đến việc có một tầng frontend và tầng phụ trợ. Vì vậy, đôi khi, tôi có thể nghe rằng họ có một giao diện với C # và một phụ trợ với Java. Tại sao bất kỳ công ty nào cũng muốn có một phụ trợ và frontend trong các ngôn ngữ khác nhau? Điều này có giúp quy mô trang web lớn tốt hơn?

Khi mọi người nói rằng frontend của họ được xây dựng trong C #, điều này có nghĩa là họ đang sử dụng một khung công tác cho frontend (như .NET) và một khung bổ sung trên phần phụ trợ (chẳng hạn như Spring)? Hay nó có nghĩa là một cái gì đó hoàn toàn khác nhau?

"Front-end" và "Back-end" có thể là những thuật ngữ mơ hồ, đặc biệt là trong các ứng dụng doanh nghiệp. "Front-end" có thể có nghĩa là UI hoặc nó có thể là toàn bộ ứng dụng. "Back-end" có thể được sử dụng để chỉ các phần bên trong, hoặc nó có thể là cơ sở dữ liệu hoặc các dịch vụ bên ngoài được sử dụng. Điều khoản có nghĩa là gì thường phụ thuộc hoàn toàn vào việc bạn đang nói chuyện với ai. Vì vậy, bạn có thể hỏi "hey, ý của bạn là gì?"

Khi bạn bắt đầu phát triển doanh nghiệp lớn, bạn sẽ có rất nhiều đội ngũ viết rất nhiều mã. Các nhóm này sẽ được phát triển bằng các ngôn ngữ khác nhau, sử dụng các mô hình khác nhau, từ các địa điểm khác nhau. Một số mã này sẽ cần phải làm việc cùng nhau và phần lớn mã này sẽ không hoạt động.

Tôi làm việc cho một ngân hàng lớn. Nhóm của tôi phát triển ứng dụng của chúng tôi trong C #. Tất cả. Nhưng chúng tôi sử dụng các dịch vụ web phần lớn được viết bằng Java và các dịch vụ đó nói chuyện với các dịch vụ khác nói chuyện với các dịch vụ khác lấy dữ liệu tài khoản đến và từ các cửa hàng dữ liệu phù hợp và ai biết ngôn ngữ nào được sử dụng với những ngôn ngữ đó.

Phiên bản ngắn: Mọi người sử dụng các công cụ hoàn thành công việc.

Tôi nghĩ bạn cần mở rộng câu hỏi một chút: Tại sao các dự án phần mềm lớn sử dụng nhiều hơn một ngôn ngữ lập trình?

Có rất nhiều câu trả lời có thể có, những câu trả lời đáng chú ý nhất là:

• Các ứng dụng lớn bao gồm nhiều phần tương đối độc lập; thông thường, mỗi phần được xây dựng bởi một nhóm khác nhau hoặc thậm chí là một nhà thầu bên ngoài khác nhau. Lợi ích của việc đi với giá thầu tốt nhất thường lớn hơn lợi ích của việc có mọi thứ trong cùng một ngôn ngữ.
• Ngôn ngữ đến và đi, và đôi khi là một thành phần của một hệ thống lớn vượt xa hệ sinh thái. Một ví dụ từ thế giới Microsoft là có bao nhiêu công ty hiện sử dụng C # cho tất cả các dự án mới, nhưng họ vẫn có một cơ sở mã VB đáng kể xung quanh. Chi phí viết lại một dự án chỉ vì mục đích thực hiện nó bằng ngôn ngữ lập trình mới nhất thực tế không bao giờ được chứng minh.
• Giao diện với các thành phần của bên thứ ba. Nếu hệ sinh thái C # của bạn cần thực hiện một nhiệm vụ cụ thể chỉ tồn tại các giải pháp Java, thì bạn có hai lựa chọn: tự thực hiện giải pháp hoặc sử dụng giải pháp Java và phát triển một chút keo để tích hợp nó vào hệ thống của bạn. Thứ hai là gần như rẻ hơn cho bất kỳ nhiệm vụ không tầm thường.

Các cân nhắc về hiệu suất thực tế không bao giờ là lý do, ngoại trừ trong các ứng dụng cực kỳ quan trọng như giao dịch tần số cao - trong các lĩnh vực đó, có thể có ích khi viết công cụ cốt lõi quan trọng bằng ngôn ngữ có hiệu suất thời gian chạy tốt hơn (giả sử, C ++), nhưng các hệ thống hỗ trợ (UI, báo cáo, v.v.) ở cấp độ cao hơn như Java hoặc C #.

Nó là tương đối trong một doanh nghiệp lớn.
Trong công ty của tôi, ngăn xếp là khoảng

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

Vì vậy, đối với nhóm phát triển web, frontend là HTML / JS và backend là Java. Đối với doanh nghiệp, frontend là Java và backend là .Net.

Trong thực tế, lớp .Net phải hoạt động với ứng dụng COBOL / UNIX cho Thanh toán và Yêu cầu và do đó, trong phối cảnh này .Net là frontend và COBOL là phụ trợ.

Và đúng như những người khác đã đề cập, chúng tôi có các nhóm gồm các nhà thiết kế UX, nhà phát triển HTML / JS, nhà phát triển Java, Web Middleware, nhà phát triển .Net, nhà phát triển SQL, nhà phát triển COBOL làm việc ở mỗi phần của ngăn xếp.

Trong thực tế, trong bất kỳ doanh nghiệp đủ lớn, nó là rùa xuống.

Ngữ nghĩa khó hiểu

Đó là một vấn đề ngữ nghĩa. Khi ai đó nói rằng nhà phát triển giao diện người dùng .NET hoặc nhà phát triển giao diện người dùng Java, họ thường nói về người biết nhiều ngôn ngữ tạo khuôn mẫu và có thể các khung không bao giờ được sử dụng như các biểu mẫu web được sử dụng để thử và ẩn chộp lấy mọi thứ trên một bức tường http (tức là "phát triển web") từ các nhà phát triển ứng dụng, những người không muốn hoặc ít nhất được cho là không muốn tìm hiểu về tất cả những thứ nhảm nhí đó. Trong trường hợp hỗn hợp .NET và Java, tôi không chắc nhưng tôi chỉ có thể đoán rằng theo nghĩa MVC của những thứ họ đã có Java hoạt động cho tất cả các công cụ mô hình kinh doanh và .NET xử lý mọi thứ khác sẽ được mô tả tốt hơn là "tầng lớp trung lưu" nhưng nó vẫn là tất cả phía máy chủ.

Sự tách biệt thực sự là những gì xảy ra trên máy chủ và những gì xảy ra trên máy khách hoặc trình duyệt. Bạn có thể dễ dàng giới thiệu việc xây dựng HTML được gửi đến hoặc đại diện cho giao diện người dùng với "phát triển giao diện người dùng" vì vậy tôi muốn tránh nhầm lẫn bằng cách sử dụng thuật ngữ máy khách và phía máy chủ thay vì phía trước và phía sau khi thảo luận về những gì tôi thường làm, (thường là công việc phía khách hàng).

Ngôn ngữ phía khách hàng

Lý do chúng tôi sử dụng cùng một bộ ngôn ngữ trên trình duyệt là vì trình duyệt nằm ở đầu nhận và phần lớn (hiện tại đã có sự kháng cự chủ yếu từ Microsoft và Adobe), không ai muốn phải gửi ba các phiên bản khác nhau của cùng một phía khách hàng để đáp ứng mọi khách hàng tiềm năng hoặc yêu cầu trình cắm độc quyền được cài đặt để web hoạt động. Ngoài ra, ba ngôn ngữ thực sự gói gọn mối quan tâm của khách hàng khá độc đáo, cho phép chúng tôi nhanh chóng xây dựng và sửa đổi giao diện ứng dụng web bằng cách duy trì khớp nối lỏng lẻo giữa cấu trúc tài liệu, mọi thứ trông như thế nào và mọi thứ hoạt động như thế nào. Bạn có thể thay đổi một cái mà không thay đổi hai cái kia khá dễ dàng.

Ngôn ngữ phía máy chủ

Lý do bạn có nhiều lựa chọn trên web phía máy chủ là vì bạn có thể. Đó là máy chủ của bạn. Tất cả những gì nó phải làm là giao tiếp qua http / ssl và phần còn lại tùy thuộc vào bạn. JavaScript bây giờ là một tùy chọn, nhưng điều đó đưa ra một câu hỏi thú vị. Nếu bạn vẫn đối xử với một ứng dụng web như thực sự là hai ứng dụng ở hai bên của bức tường HTTP đó. Tôi có ý kiến ​​thông qua nỗi đau rằng có, vâng, bạn nên và tôi yêu Node.js.

Nói tóm lại, nơi bạn có các dự án lớn, bạn cũng có nhiều nhóm nhà phát triển làm việc trong dự án và các nhóm đó có xu hướng chuyên về các lớp khác nhau của ứng dụng.

Nếu bạn đang tập trung vào giao diện người dùng web và bạn linh hoạt trong việc lựa chọn triển khai, bạn có nhiều khả năng sử dụng ngôn ngữ được nhắm mục tiêu trên web, như JScript hoặc Flex, thay vì C #.

Tương tự, nếu bạn ở cuối cửa hàng dữ liệu giao dịch của ứng dụng, xử lý nhiều hành động đồng thời cùng một lúc, các ngôn ngữ chuyên ngành như erlang có xu hướng được sử dụng. (Hoặc các sản phẩm của bên thứ ba được triển khai một phần bằng các ngôn ngữ này)

Lý do là cân bằng rủi ro kinh doanh.

Giả sử bạn là một chủ nhân khổng lồ trong một thành phố. Bạn phải thuê rất nhiều nhà phát triển để xây dựng nhiều dịch vụ khác nhau. Giả sử đánh giá ban đầu của bạn là Lanuage A phù hợp nhất với sở thích của bạn và bạn muốn bắt đầu với nó.

Nếu bạn cam kết với một công nghệ, bạn có thể làm cạn kiệt tài năng. Bạn có chắc chắn muốn thuê một anh chàng Langauge đàng hoàng khi có một ngôi sao Ngôn ngữ B ở ngay gần đó không? Điều gì sẽ xảy ra nếu ngày mai các khuôn khổ của Langauge A được hỗ trợ bởi nhà phát triển chính? Điều gì sẽ xảy ra nếu ngày mai có một Ngôn ngữ C tuyệt vời, bạn có nên bỏ qua nó vì bạn đã cam kết với ngôn ngữ A năm năm trước không?

Lý tưởng nhất bạn muốn là một hệ thống hetrogenous với các ngôn ngữ khác nhau phản ánh xu hướng công nghệ và xu hướng công nghệ hiện tại. Bạn muốn số dư này thay đổi chậm vì nhóm tài năng và xu hướng đang thay đổi để tại bất kỳ thời điểm nào, tất cả các hệ thống của bạn đều có thể hoạt động được và bạn có thể thuê người để duy trì chúng.

... Và đó là những gì các công ty làm.

Thật hữu ích khi nghĩ về mặt trước và mặt sau của bạn là các ứng dụng riêng biệt sử dụng cùng một nguồn dữ liệu.

Ngay cả đối với các trang web nhỏ hơn, bạn có thể nghĩ giao diện người dùng giống như giao diện của máy khách và giao diện người dùng giống như một CMS. Đây có thể dễ dàng là các ứng dụng MVC riêng biệt. Giao diện người dùng vẫn cần các mô hình và bộ điều khiển để chạy - xét cho cùng, bộ điều khiển là điểm truy cập cho khách truy cập trang web của bạn và các mô hình sẽ là cách bạn lấy dữ liệu từ cơ sở dữ liệu của mình đến người dùng.

Tôi có xu hướng thích sử dụng Django / Python làm CMS ở mặt sau và sử dụng Rails, CodeIgniter hoặc Spring MVC ở mặt trước. Thường không có lựa chọn nào khác; khách hàng đã có một số trang web cũ được thiết lập bằng một số ngôn ngữ ở mặt trước và họ chỉ muốn một giải pháp CMS. Hầu hết các khách hàng thậm chí sẽ không biết CMS đang chạy một ngôn ngữ hoặc khung khác nếu họ không nói.

Đó thực sự là về việc tìm kiếm những gì hoạt động tốt nhất cho trang web bạn muốn xây dựng. Mặt trước và mặt sau thực sự chỉ cần chia sẻ cơ sở dữ liệu, miễn là cả hai có thể làm việc với điều đó, hãy thoải mái chọn các tùy chọn tốt nhất cho nhiệm vụ trong tay.

Một ví dụ về ngôn ngữ back end là PHP, đây là ngôn ngữ script. Khi một trang PHP được yêu cầu, máy chủ sẽ đọc mã PHP và hiển thị đánh dấu. Kết quả là HTML được gửi cho bạn. Bạn, người xem trang web, không bao giờ thấy một dòng mã PHP. Giả sử rằng quản trị viên máy chủ web đã thực hiện đúng công việc của mình, máy chủ sẽ và không bao giờ có thể hiển thị cho bạn mã PHP thực tế. Nó được phân tích cú pháp khi trang được phục vụ và kết quả của bản dịch mã đó là HTML.