Làm cách nào để sử dụng python để phát triển web mà không dựa vào khung công tác?

Question

Tôi biết các khuôn khổ khác nhau có lợi ích của họ, nhưng cá nhân tôi muốn phát triển web của tôi trong python càng thẳng càng tốt càng tốt: ít viết cho khung, viết nhiều hơn python.

Điều duy nhất tôi đã tìm thấy cho đến nay cho phép tôi làm điều này theo cách rõ ràng nhất có thể là web.py nhưng tôi có những lo ngại nhỏ về hiệu suất của nó.

Đối với những người bạn sử dụng nginx (hoặc một hương vị khác) + mod_wsgi + web.py ... hiệu suất của nó như thế nào? Nó có thể được cải tiến hơn nữa không?

Đối với những người bạn đã sử dụng web.py, thích ý tưởng và tiếp tục viết một cái gì đó tốt hơn hoặc tìm thấy điều gì đó tốt hơn ... hãy quan tâm đến việc chỉ cho tôi nguồn?

Tôi muốn nghe về tất cả các phương pháp tiếp cận dễ thấy, tối thiểu nhưng mạnh mẽ.

Answer 1

Thật vui nhộn, thậm chí được nhắc bằng một câu hỏi hỏi cách viết mà không có khung, mọi người vẫn tham gia để quảng bá khung yêu thích của họ. OP whinges về việc không muốn một "khung nặng", và các câu trả lời đề cập đến Twisted, của tất cả mọi thứ ?! Hãy đến đây, thực sự.

Có, nó hoàn toàn có thể viết các ứng dụng WSGI thẳng và lấy các chức năng mong muốn từ các mô-đun độc lập, thay vì kết hợp mã của bạn vào một khung nhìn cụ thể của thế giới.

Để thực hiện tuyến đường này, bạn sẽ thường muốn làm quen với các khái niệm cơ bản của HTTP và CGI (vì WSGI kế thừa một số khủng khiếp từ đặc điểm kỹ thuật trước đó). Nó không nhất thiết là một cách tiếp cận để giới thiệu cho người mới bắt đầu, nhưng nó khá khả thi.

Tôi muốn nghe về tất cả các, tối thiểu cách tiếp cận dễ thấy nhưng mạnh mẽ

Bạn sẽ không nghe về họ, bởi vì không ai có lợi ích trong việc thúc đẩy bộ lạc “làm điều đó chính mình ”như một phương pháp luận. Tôi, tôi sử dụng một gói templating độc lập cụ thể, một gói đọc biểu mẫu độc lập cụ thể, một lớp truy cập dữ liệu cụ thể và một vài mô-đun tiện ích nhà-brew. Tôi không viết cho một triết lý cụ thể mà tôi có thể cải thiện, tất cả chúng chỉ là những công cụ nhàm chán có thể được hoán đổi và thay thế bằng một thứ khác tốt.

Answer 2

Đối với những gì nó có giá trị, tôi đã viết trang web của tôi trong mod_python mà không có bất kỳ khuôn khổ can thiệp nào như Django. Tôi thực sự không có lý do gì để phàn nàn cả. (Vâng có thể một chút, mod_python là loại kỳ quặc trong một vài cách nhưng không phải trong trường hợp sử dụng phổ biến) Một điều chắc chắn, nó chắc chắn sẽ cho phép bạn viết Python ;-)

Answer 3

Con đường để đi là wsgi.

WSGI là Giao diện cổng máy chủ web . Nó là một đặc điểm kỹ thuật cho các máy chủ web và các máy chủ ứng dụng để giao tiếp với các ứng dụng web (mặc dù nó cũng có thể được sử dụng nhiều hơn thế). Đây là một tiêu chuẩn Python, được mô tả chi tiết trong PEP 333.

Tất cả các khung công tác hiện tại đều hỗ trợ wsgi. Rất nhiều webserver hỗ trợ nó cũng (apache bao gồm, thông qua mod_wsgi). Đó là con đường để đi nếu bạn muốn viết khuôn khổ của riêng bạn.

Đây là hello world, ghi vào WSGI trực tiếp:

def application(environ, start_response): 
    status = '200 OK' 
    response_headers = [('Content-type','text/plain')] 
    start_response(status, response_headers) 
    return ['Hello world!\n'] 

Đặt điều này trong một file.py, chỉ cấu hình apache mod_wsgi của bạn với nó, và nó sẽ chạy. Trăn tinh khiết. Không nhập. Chỉ cần một hàm python.

Nếu bạn thực sự đang viết khung của riêng mình, bạn có thể kiểm tra werkzeug. Nó không phải là một khung công tác, mà là một tập hợp các tiện ích khác nhau đơn giản cho các ứng dụng WSGI và đã trở thành một trong những mô-đun tiện ích WSGI tiên tiến nhất. Nó bao gồm một trình gỡ lỗi mạnh mẽ, các đối tượng yêu cầu và phản hồi đầy đủ, các tiện ích HTTP để xử lý thẻ thực thể, tiêu đề kiểm soát bộ nhớ cache, ngày HTTP, xử lý cookie, tải tệp lên, hệ thống định tuyến URL mạnh mẽ và một loạt các mô-đun cộng tác đóng góp. Lấy phần nhàm chán ra khỏi bàn tay của bạn.

Answer 4

Bạn cũng có thể kiểm tra cherrypy. Trọng tâm của cherrypy là trong một khuôn khổ cho phép bạn viết python. Cherrypy có máy chủ web khá tốt, nhưng nó tương thích với wsgi nên bạn có thể chạy các ứng dụng cherrypy trong apache thông qua mod_wsgi. Đây là hello world in cherrypy:

import cherrypy 

class HelloWorld(object): 
    def index(self): 
     return "Hello World!" 
    index.exposed = True 

cherrypy.quickstart(HelloWorld()) 

Answer 5

Có gì sai với Django? Nó không ép buộc bạn sử dụng ORM và các bộ điều khiển chỉ là các hàm Python đơn giản thay vì các phương thức lớp giống như Rails. Ngoài ra, định tuyến url được thực hiện với các cụm từ thông dụng thay vì một cú pháp được tạo bằng khung khác.Nếu django có vẻ như quá nhiều đối với bạn anyway, tôi khuyên bạn nên xem Werkzeug

Answer 6

Tôi rất thích Google AppEngine. Tôi sử dụng ORM và hệ thống templating, nhưng nếu không thì hãy làm theo một thiết kế có khuôn mẫu REST và chỉ thực hiện các phương thức Python cho các HTTP tương ứng. Nó làm cho trung tâm tương tác HTTP thô và tùy chọn cung cấp cho bạn những thứ khác để sử dụng. Ngoài ra, không còn phải định cấu hình và quản lý môi trường triển khai của bạn nữa!

Answer 7

Tôi đã viết một vài ứng dụng web nhỏ bằng cách sử dụng mod-python và PSP - mod-python tương đương với php.

Trong một trường hợp, tôi đã viết một trang web tạo ghi chú phát hành bằng cách kiểm tra kho lưu trữ mã nguồn của chúng tôi. Tôi viết lại nó thành PHP, và ngạc nhiên khi phát hiện ra rằng phiên bản PSP nhanh hơn khoảng 20%, cũng như khoảng một nửa số dòng mã.

Vì vậy, đối với các vấn đề nhỏ ít nhất, psp đã làm việc tốt cho tôi.

Answer 8

+1 cho tất cả các câu trả lời với WSGI.

Eric Florenzo đã viết một bài đăng blog tuyệt vời gần đây bạn nên đọc: Writing Blazing Fast, Infinitely Scalable, Pure-WSGI Utilities. Điều này sẽ cung cấp cho bạn một ý tưởng tốt hơn về WSGI tinh khiết ngoài Hello World. Cũng chú ý đến các ý kiến, đặc biệt là bình luận đầu tiên của Kevin Dangoor, nơi ông đề nghị ít nhất thêm WebOb vào bộ công cụ của bạn.

Answer 9

Tôi nghĩ điều đó phụ thuộc vào định nghĩa về khung làm việc là gì và nó nên làm gì cho bạn.

Như đã chỉ ra, một "khung công tác" rất nhỏ sẽ là WSGI vì nó chỉ định nghĩa một giao diện nhỏ để giao tiếp với máy chủ web. Nhưng đó là một cách tiếp cận mạnh mẽ vì phần mềm trung gian mà bạn có thể đặt giữa ứng dụng và máy chủ của mình.

Nếu bạn muốn nhiều hơn một chút, giống như một số URL để lập bản đồ chức năng, thì bạn có một số lựa chọn, một số đã được đề cập.

Nếu bạn đi xa hơn, bạn có thể đến Pylons hoặc Turbogears hoặc Django, sau đó có thể Zope nhưng nó phát triển lớn hơn và có thể là nỗi đau cũng như bạn luôn luôn mua vào ý kiến ​​của khuôn khổ đó.

Những gì tôi sử dụng gần đây ngày càng nhiều (đến từ Zope/Plone) là repoze.bfg. Nó rất nhỏ, không đi kèm với gói ORM (vì vậy bạn có thể sử dụng SQLAlchemy, Storm hoặc đơn giản là đi đến một cơ sở dữ liệu đối tượng như ZODB). Những gì nó làm là về cơ bản xử lý như thế nào bạn đến từ một URL để xem đó là một chức năng. Nó hỗ trợ cả hai bản đồ URL (a la Routes) hoặc đối tượng traversal, mà IMHO là rất mạnh mẽ trong một số trường hợp đặc biệt. nếu bạn có một bản đồ không quá nghiêm ngặt. Điều tốt là nó trực tiếp đi kèm với một khuôn khổ bảo mật dựa trên ACL mà có thể sử dụng nếu bạn muốn IMHO là rất thiết thực để có. Bằng cách đó bạn không cần trang trí mà dường như được sử dụng chủ yếu cho những thứ như vậy.

Và tất nhiên nó dựa trên WSGI. Cũng tìm kiếm repoze subversion repository cho khá nhiều phần mềm trung gian và các công cụ Paste cũng rất hữu ích cho các tác vụ liên quan đến WSGI.

Answer 10

Tại sao bạn có thắc mắc về hiệu suất của web.py? Như tôi đã đề cập here, chúng tôi sử dụng CherryPy (máy chủ web "được tích hợp trong" web.py) sau nginx để phân phát hầu hết HTML tại Oyster.com - nginx chia lưu lượng truy cập trên 2 hoặc 3 máy chủ web mỗi lần chạy 4 quy trình Python, và chúng tôi có thể dễ dàng xử lý 100 yêu cầu mỗi giây.

Oyster.com là trang web có khối lượng lớn trung bình 200.000 lần xem trang/ngày được tạo động và đạt đến con số cao hơn nhiều so với số trang đó. Tuy nhiên, chúng tôi sử dụng mạng phân phối nội dung (CDN) cho các tài nguyên tĩnh của chúng tôi như hình ảnh và CSS.

Chúng tôi chắc chắn quan tâm đến hiệu suất (hầu hết các trang của chúng tôi hiển thị trong chưa đầy 25ms), nhưng web.py không phải là nút cổ chai. Các nút cổ chai của chúng tôi là hiển thị mẫu (chúng tôi sử dụng Cheetah, đủ nhanh nhưng không nhanh chóng khác) và truy vấn cơ sở dữ liệu (chúng tôi lưu trữ rất nhiều và giữ số lượng truy vấn cơ sở dữ liệu trên mỗi trang đến 0 hoặc 1) và truy cập vào giá của khách sạn bên thứ ba của chúng tôi nhà cung cấp (chúng được truy cập khi bạn thực hiện tìm kiếm với những ngày mà chúng tôi chưa lưu trữ).

Hãy nhớ rằng, tối ưu hóa sớm là gốc rễ của tất cả các điều ác - trừ khi bạn đang phục vụ google.com, web.py có thể sẽ làm việc cho bạn.