I am setting up an Eve instance for production and wonder what is the "preferred production setup" for Eve - if there is such a thing.
uWSGI seem to work nice.
Gunicorn works nice with standard Flask - but not so easily for Eve as Eve has an implicit import of "settings.py".
Suggestions or recommandations?
Tornado is pretty popular with Eve and Flask in general. Because it is non-blocking and uses epoll, it can handle thousands of simultaneous standing connections, which means it is ideal for real-time web services. Integrating this service with Flask is straightforward (source).
So imagine you have your average run.py script for launching your REST API:
from eve import Eve
app = Eve()
# custom stuff here
if __name__ == '__main__':
app.run()
You could then have a run-production.py script like this:
from tornado.wsgi import WSGIContainer
from tornado.httpserver import HTTPServer
from tornado.ioloop import IOLoop
from run import app
http_server = HTTPServer(WSGIContainer(app))
http_server.listen(5000)
IOLoop.instance().start()
You can then launch run.py when debugging, and run-production.py when going live.
Related
I'm creating a web application that has Angular for front end and Flask for back end. I already 'dockered' my applications but I'm not sure on how to get them in Heroku as the same application
I've been reading that some people has used a reverse proxy server (this means that both applications are in different heroku app and they connect them using a proxy like traeffik or haproxy). But I don't want to do this, I want them to be in the same application (Example: grupo-camporota.herokuapp.com)
I was thinking that I should push both images, one as web dyno (front) and the other one as a worker (backend) but I've read that the worked dyno it's not for this, but for EXTERNAL apis. I would like to upload both image into heroku and make them communicate between them.
I would like to know how to get this done (I'm pretty sure it's possible), since i'm kinda lost
Your backend can't be a worker dyno: only web dynos can receive traffic from the internet. And one app will only get a single port to listen on, so you can't run two services on a single app.
You could serve your front-end up from your back-end as static files, but I don't think that will work with Docker. Also, Flask doesn't like to serve static files itself, so that may not be a good fit either.
It also looks like you can't communicate between Docker containers using a private network on Heroku. You may just have to deploy two apps (or host your front-end on a more appropriate static host).
I have developed a web application using the aiohttp module (the web part) and haven't encountered any issues so far.
Though, when I try to deploy it to my hosting service (NameCheap), I am asked for the "application startup file" (so I guess it is the Python script I run to start the website, in my case name.py) and the "application entry point" (as a hint, I'm given Setup wsgi callable object for your application). I'm clueless about that. I've seen some things about how to use uWSGI with Flask and Django but nothing for aiohttp.
Is there any way to make things work here, or should I get a VPS instead of a "regular" web hosting service?
aiohttp is not WSGI framework PEP 333 and PEP 3333 but TCP socket server.
I know nothing about NameCheap hosting, sorry. aiohttp deployment page provides basic information about aiohttp server deployment.
100k of wakama clients concurently hitting to leshan server with out jmeter or any testing tools in python
A python client in git is found which has wrote using asyncio coroutines i would like to modify the client code and achieve concurent hits of the clients how will be achieved?
I am currently using the python package distributed, does anyone know that how to get the address of the web UI when set up with Python API?
executor = Executor()
Or I always have to set up with the command line
dask-scheduler
to get the address of the Web UI?
You can start the web interface with the following command:
>>> executor.cluster.start_diagnostics_server()
INFO - Bokeh UI at: http://127.0.0.1:8787/status/
This will then print out the address of the web interface. However it will almost always be at http://localhost:8787/status/.
This requires Bokeh to be installed.
I wrote a real-time web app that consists of the following:
Rails to serve the web pages (listens on port 80)
Nodejs to handle real-time logic (listens to port 8888)
So on a particular page served by my rails app, the JS will use socket.io to establish a connection to my nodejs instance to allow real time http push.
Currently Nodejs communicates with Rails simply by updating the rails database. (I know this is ghetto but it works).
What are my options for deployment?
I have deployed simple web apps on heroku before and I really like the simplicity.
I have also deployed a web app with similar functionality (except it's made up of django + nodejs). I used HAProxy to do reverse proxying to handle direction of traffic to the correct process on my machine. However, I deployed this on a VPS server instead.
Note: the ugliness will probably revolve around:
I am relying on a common db
These processes are listening on different ports
We had this exact issue. We deployed them to separate Heroku applications, but kept them within the same code base. http://techtime.getharvest.com/blog/deploying-multiple-heroku-apps-from-a-single-repo outlines how to do it.
Manually set the buildpack
Set a config variable that you can reuse in step #3.
Create a custom web script that your Procfile uses
A custom script in bin/web
#!/bin/bash
if [ "$RAILS_DEPLOYMENT" == "true" ]; then
bundle exec rails server -p $PORT
else
node node/index.js
fi
And the Procfile:
web: bin/web
I would consider setting these two applications up as separate Heroku applications on different subdomains and just having them both on port 80. The communication between them goes through a shared database so they don't need to reside on the same machine or even datacenter. Socket.io supports cross domain requests on all browsers, so that shouldn't cause any problems.