search

bottlepy / bottle

bottle.py is a fast and simple micro-framework for python web-applications.
http://bottlepy.org/
MIT License
8.37k stars 1.46k forks source link

Releasing 0.13.0? #1198

Closed noamtamim closed 1 week ago

noamtamim commented 4 years ago

I love Bottle, and I want to use it with a production-grade server. However:

  1. Of the multi-threaded servers, the latest release only supports waitress (Cheroot and latest CherryPy are not supported, paste is dead)
  2. The docs says that to use the async servers (the majority) I need to "design your application accordingly". I don't know what it means because there are no details.
  3. 0.13.0 is still in development and I'd rather not use it for production as long as it's not released.

What do you suggest?

PyB1l commented 4 years ago

I use bottle in production for 4 years now and it's quite stable.

  1. You can use gunicorn or uWSGI with for multithread/ multiprocess server setups. If non blocking IO is forced by application scope (i.e many external services, concurrent DB IO) you can always use Gevent which plays well with bottle. (Use a variant of GeventServer that will be fine with any version of bottle)

  2. Gevent solves the following issue: While your web framework supports event loops, your popular Database tools don't. Async (at least for now) has no mature libraries that you will need in real life web development. For instance asyncpg is really cool but is too low level compared to SqlAlchemy. On the other hand, wit gevent you can use most of your libraries, thus it provides a more end-to-end solution.

  3. I want 0.13 for stable too, but until then 0.12 must do the job.

oz123 commented 4 years ago

I am using 0.13 for more than 2 years in production. No serious problems encoutered. It's rock solid, and if there are problems they are usually my fault!

defnull commented 4 years ago

We are working on 0.13, but the release is tricky as it drops a range of legacy python versions and adds a ton of changes. We usually try to provide backwards compatibility from x.y.latest to x.y+1 and that is really hard to guarantee this time. I would not hold my breath.

1) Bottle is a WSGI framework. It works with any WSGI server out there and you can simply follow the documentation of the server of your choice. The server adapters are completely optional. 2) @PyB1l described it nicely. Most modern WSGI servers are asyncronous under the hood (async network IO), but still call the WSGI callable in a thread pool. If you really need hundreds or thousands of long-running connections (e.g. for websockets), gevent is a good choice. Or ditch WSGI and switch to a pure async framework. There are plenty nowadays. 3) The master branch is usable, even in production, as long as you watch it and stay involved. It is not stable, though. Updates may break things. However, there is no real reason to upgrade if you do not need a new feature or are affected by a bug. Security issues are extremely rare.

noamtamim commented 4 years ago

Thank you all for the insightful responses. Questions to @defnull:

  1. Given that 0.13 has a lot of changes and Bottle itself is very mature, wouldn't it be a better to call it 1.0?
  2. What do you mean by "ditch WSGI and switch to a pure async framework"?
  3. For simplicity and given what I wrote in the issue description, I set Bottle to use Waitress as the server instead of CherryPy and wsgiref. Is it a good choice or should I select another server?
defnull commented 4 years ago

1) We can call it "Henry" and paint it blue, makes no difference. I like the zero-based version as it reduces the expectations and encourages users to look into the code when they have a problem. It keeps away the "Why does this not work as I expected? Bottle sucks, flask rules!" users. Not sure if there will ever be a 1.0 :) That said, I'm thinking about skipping 0.13 and release 0.14 next, to make it clear that this release may have breaking changes. If you are on Python 2, you are stuck with 0.12 anyway. 2) WSGI is a protocol (defined in PEP-3333) the HTTP server uses to speak with an application. It was designed way before asyncio was a thing. There are other protocols (ASGI) or frameworks that bring their own HTTP server implementation (twisted) that better support fully asynchronous applications. If you really need that (most don't), look into those. 3) Depends on your workload. For production I'd go for nginx and uWSGI, or put a couple of waitress/cheroot instances behind an nginx load-balancer.

defnull commented 1 week ago

A lot happened in the last couple of days. In short: Bottle 0.13 just released, 0.14 may end up becoming 1.0 but that is still undecided. The other questions in this issue were answered I think, so I'm closing this. Thanks all :)