2012-03-29 55 views
16

Bạn có thể tư vấn cho tôi một số bài viết/ứng dụng cho phép bạn tạo ứng dụng SaaS (Phần mềm dưới dạng Dịch vụ) với Python và Django hay không.Cách tạo ứng dụng SaaS bằng Python và Django

Đối với thời điểm hiện tại các chủ đề chung tôi không hiểu là:

  1. Bạn có một ứng dụng làm việc cho tất cả các khách hàng hoặc một ứng dụng cho mỗi khách hàng
  2. Làm thế nào để bạn quản lý truy cập cơ sở dữ liệu, cho phép hoặc DB khác nhau cho mỗi khách hàng
  3. có bất kỳ công cụ cho phép bạn chuyển đổi một ứng dụng SaaS
+3

Nó sẽ rất thú vị nếu bạn đăng phản hồi của riêng bạn ở đây sau 4 năm. Trong trường hợp bạn tiếp tục làm việc trong dự án. Cảm ơn. –

+2

@imanis_tn tốt, 4 năm sau rất nhiều thứ xảy ra nhưng đây là phần quan trọng. Tôi đã làm việc trên một ứng dụng SaaS gọi là Nhận Bản tin. Chúng tôi đã sử dụng khung công tác REST Django để xây dựng API của chúng tôi nhưng chưa sử dụng bất cứ điều gì đặc biệt. Không có tên miền phụ cho mỗi người dùng, hệ thống thanh toán nội bộ và chúng tôi đã xử lý các quyền theo đối tượng theo cách thủ công. Thực ra khi tôi tham gia dự án đã đề cập ở trên, hệ thống đã được thiết lập và chạy, và chúng tôi mới bắt đầu tạo REST Api để chúng tôi bị hạn chế bởi codebase hiện tại nhưng kết quả khá tốt. –

Trả lời

31
  1. một dự án, điều này sẽ giúp bảo trì dễ dàng hơn. Tôi xử lý độ phân giải máy chủ với phần mềm trung gian trong django-ikari.
  2. bạn thì không. xem # 1
  3. tôi sử dụng như sau:

  4. Trong khi không cần thiết, sau đây sẽ giúp đỡ trong thời gian dài:

    • django-hunger: đăng ký beta tin
    • django-waffle: Tính năng lật
    • thẻ django-classy: tạo mẫu templatetag đẹp, dễ dàng và gọn gàng
    • django-merchant: cổng thanh toán trừu tượng
    • django-mockups: thử nghiệm nhanh với các mô hình
    • django-merlin: biểu mẫu tốt hơn nhiều bước (thuật sĩ)
  5. Cuối cùng, tốt đẹp để có

+2

Nếu bạn đã có một Cms/framework có thể cấu hình khoảng 3 + 4, tôi sẽ trả tiền cho điều đó. –

+0

Tại sao bạn thích django-userprofiles? –

+0

P.s. một số trong số đó là GPL (ví dụ: Ikari, Thanh toán). Tôi không biết liệu điều đó có phức tạp không. –

5

Software as a Service chỉ là một từ tiếp thị, nó về mặt kỹ thuật không khác gì từ một máy chủ có thể truy cập qua internet. Vì vậy, câu hỏi 3 không có ý nghĩa. Điều đó để lại cho chúng tôi câu hỏi 1 và 2:

  1. Ý của bạn là gì với 'ứng dụng' trong ngữ cảnh này? Ứng dụng web của bạn (được xây dựng với Python và Django) có thể có nhiều ứng dụng Django (các thành phần tạo nên ứng dụng web) nhưng tôi nghĩ đó không phải là ý của bạn. Bạn có thể xây dựng trang web của bạn bằng Python/Django và có nhiều tùy chọn tùy chỉnh tùy thuộc vào người dùng (client) nào được đăng nhập. Ví dụ, một khách hàng cao cấp có thể có nhiều tùy chọn nâng cao nhưng nó vẫn là một phần của cùng một codebase. Nó chỉ là một số tùy chọn (nút/điều khiển, vv) không được hiển thị cho một số khách hàng nhất định

  2. Django có rất nhiều công cụ để quản lý người dùng, quyền và nhóm. Bạn có thể cung cấp cho mỗi người dùng (mỗi khách hàng) các quyền khác nhau và các quyền này xác định những gì họ có thể làm. Truy cập cơ sở dữ liệu phải được ứng dụng web của bạn quản lý. Ví dụ, mã xác định thông tin nào cần được hiển thị trên trang web (tùy thuộc vào máy khách nào được đăng nhập) và mã đó lấy thông tin từ cơ sở dữ liệu. Tùy thuộc vào quy mô mà bạn đang nhắm tới, bạn cũng có thể chỉ định cơ sở dữ liệu nào sẽ được sử dụng để truy xuất thông tin từ đó.

+0

Câu hỏi chắc chắn 3 có ý nghĩa (ít nhất là khi nó đọc hiện tại) - chuyển đổi "một ứng dụng" có thể có nghĩa là một ứng dụng Windows GUI, một ứng dụng dòng lệnh unix, hoặc bất kỳ số thứ nào. –

6

Ví dụ cơ bản, cơ bản về cách bạn thực hiện.

Giả sử bạn có một ứng dụng đơn giản được thiết kế để giải quyết một trường hợp kinh doanh cụ thể. Ví dụ: bạn đã tạo một ứng dụng để xử lý việc đặt phòng tại văn phòng của bạn.

Để "chuyển đổi" ứng dụng này thành một dịch vụ , bạn phải định cấu hình sao cho hầu hết các phần của người dùng cụ thể là tham số (chúng có thể được "templatized" - vì thiếu từ tốt hơn).

Đây là cách giao diện người dùng được chuyển đổi. Bạn có thể tạo các biến để giữ biểu trưng, ​​dòng tiêu đề, trêu ghẹo, lược đồ màu cho ứng dụng; cho phép mỗi người dùng tùy chỉnh cá thể của họ.

Cho đến nay, ứng dụng của bạn có thể tùy chỉnh chính nó ở giao diện người dùng. Nó vẫn đang sử dụng cùng một cơ sở dữ liệu được thiết kế trong giai đoạn một.

Hiện tại, vấn đề chỉ hiển thị những trường có liên quan đến một người dùng cụ thể. Điều này sẽ được tham số hóa cơ sở dữ liệu. Vì vậy, bạn có thể thêm một cột xác định mỗi hàng là thuộc về một người dùng cụ thể; sau đó tạo các khung nhìn hoặc các thủ tục lưu sẵn để lọc các bản ghi dựa trên người dùng đã đăng nhập.

Hiện tại, ứng dụng có thể được "thuê"; vì bạn có thể tùy chỉnh cá thể dựa trên người dùng.

Sau đó, nó trở nên lớn hơn từ đây - tùy thuộc vào quy mô, loại và tùy chỉnh dự định của ứng dụng của bạn. Bạn có thể quyết định rằng ứng dụng của bạn hoạt động tốt hơn khi mỗi người dùng có cơ sở dữ liệu riêng của họ thay vì kết hợp thủ tục lưu trữ + xem.

Bạn có thể quyết định rằng đối với một số loại người dùng (hoặc "gói"), bạn cần một phiên bản ứng dụng chuyên dụng đang chạy. Vì vậy, đối với người dùng "cao cấp" hoặc "cực", bạn muốn có hệ thống riêng của họ đang chạy.

Nếu ứng dụng của bạn yêu cầu nhiều bộ nhớ - bạn có thể quyết định tính phí riêng để lưu trữ.

Điểm mấu chốt là nó không liên quan gì đến ngôn ngữ được sử dụng. Đó là một vấn đề về kiến ​​trúc và thiết kế.

0

Tôi có một số blog post mô tả đề xuất của tôi về cách đi ab tạo ra một ứng dụng web SAAS đa người thuê sử dụng Django. Nhiều thuê nhà ở đây có nghĩa là khi người dùng đăng ký, họ có tên miền phụ của họ.Để tóm tắt lại:

  • Tất cả người thuê đều dùng chung một cơ sở dữ liệu nhưng mỗi lược đồ có một lược đồ riêng. Hãy tưởng tượng bạn có trang web abc.com và ai đó đăng ký một xyz thuê nhà để họ truy cập vào trang của họ thông qua xyz.abc.com, sau đó cho một người thuê nhà xyz bạn có một giản đồ riêng biệt có chứa tất cả các bảng do đó đóng gói dữ liệu chỉ liên quan đến xyz đối tượng thuê. Có nhiều cách khác, như có một cơ sở dữ liệu và một lược đồ cho tất cả, hoặc thậm chí có cơ sở dữ liệu riêng biệt. Nhưng cách tiếp cận lược đồ là sự cân bằng tốt nhất. Tài liệu của thư viện django-tenants chứa thông tin chi tiết hơn nếu bạn quan tâm
  • Sử dụng thư viện django-tenants để làm việc trừu tượng với người thuê nhà. Khi ai đó truy cập xyz.abc.com, bạn cần biết rằng xyz là đối tượng thuê và bạn nên sử dụng lược đồ xyz. Thư viện django-tenants thực hiện điều này cho bạn, cứ mỗi yêu cầu bạn có thể lấy đối tượng thuê bằng cách chỉ cần thực hiện current_tenant = request.tenant
  • Bạn cần phân biệt giữa các bảng được chia sẻ và bảng dành riêng cho người thuê. Ví dụ, có bảng với danh sách các đơn đặt hàng là cụ thể của người thuê nhà. Mỗi người thuê nhà có thể có cơ sở dữ liệu riêng của họ có chứa tất cả các đơn đặt hàng của họ. Bảng này phải nằm trong sơ đồ xyz. Đồng thời, bạn sẽ có một số bảng Django lõi, như người dùng. Ví dụ: dữ liệu có thể được chia sẻ để không cho phép hai người dùng đăng ký bằng cùng một email.
  • Bạn cần phải cấu hình DNS của bạn để bắt một biểu thức wildcard * .abc.com, mà bạn có thể thêm một Một kỷ lục bên trong CPanel của bạn với *.abc.com liên kết đến các IP của máy chủ của bạn
Các vấn đề liên quan