Đây có phải là thiết kế bình thường để tách rời hoàn toàn các ứng dụng web phụ trợ và frontend và cho phép chúng giao tiếp với API REST (JSON) không?

Tôi đang tạo ứng dụng web kinh doanh mới và tôi muốn đạt được:

• Sử dụng các công nghệ tốt nhất từ ​​các lĩnh vực tương ứng của họ. Tôi muốn khung phụ trợ đáng tin cậy với ORM vững chắc. Và tôi muốn khung công tác SPA (ứng dụng một trang) tiên tiến nhất với việc sử dụng các tính năng HTML và Javascript cập nhật nhất cho ứng dụng lối vào
• Đưa ra các thực thể phụ trợ và dịch vụ kinh doanh để sử dụng từ các loại ứng dụng khác nhau - ví dụ: ứng dụng web, di động (Android) và có thể các loại khác (thiết bị thông minh, v.v.)

Vì vậy - để đáp ứng cả hai yêu cầu, tôi có xu hướng tách biệt hoàn toàn ứng dụng của mình trong các ứng dụng phụ trợ và frontend và tổ chức giao tiếp giữa chúng bằng API REST (JSON). Đây có phải là cách tiếp cận âm thanh?

Sự tách biệt như vậy không phải là giải pháp thiết kế rõ ràng, bởi vì nhiều công nghệ ứng dụng web đã tích hợp các lớp khung nhìn trong đó ứng dụng phía máy chủ ít nhiều kiểm soát việc tạo ra khung nhìn và xử lý một phần các phản hồi từ khung nhìn (ví dụ SpringMVC có lớp xem, PHP Yii với chế độ xem lớp, Java JSF / Facelets hoàn toàn lưu trạng thái của các thành phần của chúng trên máy chủ). Vì vậy - có nhiều công nghệ xung quanh đề xuất khớp nối mạnh mẽ hơn và hứa hẹn thời gian phát triển nhanh hơn và hành trình con đường chuẩn hơn. Vì vậy - tôi phải thận trọng khi bắt đầu sử dụng các công nghệ theo cách không được sử dụng rộng rãi.

Theo tôi hiểu thì giao diện SPA tách biệt hoàn toàn thường xuất phát từ sự cần thiết phải sử dụng API của bên thứ ba. Nhưng thiết kế âm thanh tách rời như vậy khi cả phụ trợ và frontend được phát triển bởi một công ty?

Sự lựa chọn công nghệ của tôi hiện tại là Java / Spring backend và Angular2 / Web Components / Polymer cho frontend - nếu tôi được phép nói điều này. Nhưng điều đó không liên quan đến câu hỏi này, bởi vì câu hỏi này là về thiết kế chung chứ không phải về sự lựa chọn công nghệ cụ thể?

Đây có phải là thiết kế bình thường để tách rời hoàn toàn các ứng dụng web phụ trợ và frontend và cho phép chúng giao tiếp với API REST (JSON) không?

Có nó là bình thường. Nhưng nó chỉ bình thường nếu bạn cần có sự tách biệt đó và bạn không buộc thiết lập này vào ứng dụng tổng thể của mình.

Một SPA đi kèm với một vài vấn đề liên quan đến nó. Bây giờ chỉ là một vài thứ xuất hiện trong tâm trí tôi:

• Nó chủ yếu là JavaScript. Một lỗi trong một phần trong ứng dụng của bạn có thể khiến các phần khác của ứng dụng hoạt động do lỗi Javascript đó. Với các trang được phục vụ từ máy chủ (SpringMVC, PHP, v.v.), bạn tải lại một phần mới;
• CORS . Không nhất thiết là bắt buộc nhưng thường thì back-end nằm trên một tên miền khác với front-end. Vì vậy, bây giờ bạn phải đối phó với các vấn đề bảo mật trình duyệt;
• SEO . Có phải bạn cần điều này? Trang web của bạn có công khai không? Google có thể hiểu Javascript và cố gắng hiểu ý nghĩa của trang web của bạn, nhưng về cơ bản, bạn sẽ kiểm soát bot và hy vọng điều tốt nhất. Lấy lại quyền kiểm soát có thể có nghĩa là phải dựa vào các công cụ khác như PhantomJS .
• ứng dụng front-end riêng biệt có nghĩa là các dự án riêng biệt, đường ống triển khai, công cụ bổ sung, v.v;
• bảo mật khó thực hiện hơn khi tất cả các mã nằm trên máy khách;

Chắc chắn, cũng có những lợi thế của SPA:

• hoàn toàn tương tác ở mặt trước với người dùng và chỉ tải dữ liệu khi cần từ máy chủ. Vì vậy, đáp ứng tốt hơn và trải nghiệm người dùng;
• tùy thuộc vào ứng dụng, một số xử lý được thực hiện trên máy khách có nghĩa là bạn dành máy chủ cho các tính toán đó.
• có tính linh hoạt tốt hơn trong việc phát triển back-end và front-end (bạn có thể làm điều đó một cách riêng biệt);
• nếu back-end của bạn về cơ bản là một API, bạn có thể có các ứng dụng khách khác ở phía trước như ứng dụng Android / iPhone gốc;
• việc phân tách có thể giúp các nhà phát triển front-end thực hiện CSS / HTML dễ dàng hơn mà không cần phải có ứng dụng máy chủ chạy trên máy của họ.

Vì vậy, điều này là có những lợi thế và bất lợi cho cả hai phương pháp (SPA so với các trang máy chủ). Dành thời gian nghiên cứu cả hai lựa chọn và sau đó chọn dựa trên tình huống của bạn.

Câu trả lời cho câu hỏi của bạn rất đơn giản. Vâng. Những gì bạn đề xuất là một cách tiếp cận âm thanh . Nhưng sau đó, điều tôi nghĩ bạn muốn hỏi là liệu đó có phải là một cách tiếp cận tốt hơn không , và thật không may, không ai trong chúng tôi có thể trả lời điều đó cho bạn. Các yếu tố liên quan kéo dài quá nhiều khía cạnh mà không tiết lộ mọi thứ về cả tổ chức của bạn và các yêu cầu sản phẩm, không có kết luận thực sự nào có thể được đưa ra. Tôi nghĩ rằng bạn đã biết phải làm gì anyway.

Bình thường với hãy cẩn thận.

khung javascript front end bị giới hạn trong những gì họ có thể làm. Nếu bạn tạo apis thô để sử dụng cho nhiều ứng dụng, họ thường yêu cầu một số xử lý phía máy chủ của các cuộc gọi api thô vào các mô hình xem hoạt động với ứng dụng cụ thể đó.

Do đó, kiến ​​trúc 'bình thường' có thể là:

database
business logic services (dll)
api exposing business logic
server side website exposing viewmodels and functionality via json rest endpoints
client side javascript implementing ui

Bây giờ nếu bạn chỉ có một ứng dụng web, bạn có thể cắt lớp 'api phơi bày logic nghiệp vụ' và chỉ cần có mã web phía máy chủ gọi trực tiếp logic nghiệp vụ.

Bởi vì bạn đã tách logic nghiệp vụ vào thư viện riêng của mình, nó vẫn tách rời khỏi logic ui và bạn luôn có thể thêm một lớp dịch vụ sau này.

Tương tự, vì dịch vụ api được gọi bằng mã phía máy chủ, bạn không bị giới hạn giao tiếp http. (mặc dù hiện tại nó khá phổ biến)

Ngoài ra, có javascript gọi cùng một máy chủ mà nó được phục vụ từ đó có nghĩa là bạn không phải loay hoay với cors