Các phương pháp phân tách front-end và full-javascript?


31

Giả sử tôi có một giao diện người dùng chủ yếu là một ứng dụng một trang được viết bằng cách sử dụng góc cạnh, lẩm bẩm và bower. Và giả sử tôi có một phụ trợ, phần lớn chỉ là API REST nằm trên ORM, lưu trữ / truy xuất các đối tượng từ cơ sở dữ liệu, sử dụng những thứ như grunt, express và sequelize.

Ứng dụng góc cạnh thực hiện tất cả các công cụ trực quan mà người dùng nhìn thấy, nhưng nó làm như vậy bằng cách là một GUI trên các dịch vụ được cung cấp bởi back-end.

Sẽ là mong muốn để tách chúng thành hai cơ sở mã khác nhau, để cho phép phát triển độc lập, tạo phiên bản, tích hợp liên tục, thúc đẩy phát triển, v.v.

Câu hỏi của tôi là, những phương pháp nào hiện có để làm điều này sạch sẽ? Có khuyến nghị thực hành tốt nhất cho javascript đầy đủ không?

Tùy chọn # 1 dường như là một khối nguyên khối, tức là "không tách chúng ra". Điểm chuyên nghiệp là chuỗi xây dựng rất đơn giản và mọi thứ đều ở một nơi - nhưng dường như có nhiều nhược điểm; khó hơn để phiên bản độc lập, mặt trước bị hỏng có nghĩa là mặt sau không thể triển khai, v.v.

Tùy chọn # 2 dường như là một khối đơn, trong đó chuỗi xây dựng mặt trước dẫn đến việc viết một loạt các tệp vào mặt sau. Thư mục distở mặt trước sẽ đề cập đến một số thư mục ở mặt sau, vì vậy về cơ bản khi mặt trước thu nhỏ, làm xấu đi, v.v., nó kết thúc xuất bản lên mặt sau, chạy mọi thứ.

Tùy chọn # 3 dường như tách biệt hoàn toàn: front-end và back-end đều chạy các máy chủ của riêng họ trên các cổng khác nhau và chúng là các dự án hoàn toàn riêng biệt. Hạn chế có vẻ là chúng cần được cấu hình để biết về các cổng của nhau; mặt sau phải cho phép CORS từ mặt trước và mặt trước cần biết vị trí của tất cả các điểm cuối đó.

Tùy chọn # 4 có thể là sử dụng một cái gì đó như docker-compose để kết hợp tất cả mọi thứ lại với nhau.

Tôi chắc chắn có những lựa chọn khác. Thực hành tốt nhất được đề nghị là gì?

Câu trả lời:


18

Đây là một ứng dụng front-end, back-end, với giao diện REST ở giữa. Bạn đã có sự tách biệt hoàn toàn.

Phiếu bầu của tôi là cho tùy chọn # 3. Bạn có vẻ lo lắng về cấu hình, nhưng đó là toàn bộ vấn đề. Cấu hình cho phép bạn có sự phân tách hoàn toàn mà không yêu cầu các ràng buộc mã được liên kết chặt chẽ. Nếu bạn lo lắng về CORS, hãy đặt mọi thứ trên một miền. Nếu bạn phải có CORS, cách tốt nhất để quản lý đó là cấu hình.

Nhưng không có "thực hành tốt nhất" ở đây. Thực hành tốt nhất là một trong những sẽ đáp ứng tốt nhất nhu cầu cụ thể của bạn.


2
Làm thế nào bạn có thể đặt mọi thứ vào một tên miền nếu chúng là hai máy chủ riêng biệt? Ngay cả khi chúng chạy trên cùng một máy chủ, chúng vẫn phải ở các cổng khác nhau, khiến chúng có nguồn gốc khác nhau.
FrobberOfBits

1
Nếu không có cách thực hành tốt nhất, có những ví dụ có sẵn về cách cấu hình này được thực hiện không?
FrobberOfBits

7
Bạn có thể đặt một proxy ngược (nginx) ở phía trước của ứng dụng của bạn và gắn /vị trí để localhost:3000(frontend server) và /api/đến localhost:3001(server api). nginx sẽ nghe cổng http mặc định rồi.
nvartolomei

@nvartolomei Tôi đồng ý với việc sử dụng proxy ngược. Có cách nào để chia sẻ sạch sẽ một số thông tin giữa phụ trợ, giao diện người dùng, như thông tin tuyến đường không? Ngoài ra, có dễ dàng để trỏ proxy ngược của bạn vào CDN không?
Andrew Allbright

6

Có, bạn nên tách hai ứng dụng và coi ứng dụng giao diện người dùng như ứng dụng bên thứ 3 - cuối cùng bạn có thể thêm một ứng dụng khách khác, một ứng dụng di động và nếu ứng dụng khách đầu tiên được xây dựng theo cách này, cuộc sống của bạn sẽ dễ dàng hơn.

Sử dụng bộ chứa docker hoặc hệ thống triển khai khác chủ yếu liên quan đến phần phụ trợ, vì phần đầu của ứng dụng của bạn chỉ là các tài sản tĩnh cần được giải quyết. Bạn có thể lưu trữ các tài sản đó một cách tĩnh trong máy chủ của mình hoặc ở nơi nào khác như CDN như đám mây.

Tránh các cors sẽ giúp bạn tiết kiệm được một cấu hình nhỏ, nhưng như câu trả lời ở trên đã đề cập, đó là vấn đề quan trọng. Sử dụng cors (và mã thông báo auth) sẽ giúp chuẩn bị tốt hơn phần phụ trợ của bạn cho các khách hàng khác.

Chỉnh sửa: theo như thực hành tốt nhất stack stack js - Tôi sẽ chỉ nói điều này, nhất quán. Nếu bạn đang sử dụng lời hứa (và bạn nên), hãy thực hiện ở cả hai bên. Giữ nguyên kiểu và định dạng js, sử dụng cùng libs thử nghiệm (nếu có thể), v.v.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.