I'm building microservices app that supposed to launch tests in separate containers. I also want to stream log messages to frontend and store them in database and I don't know what solution would be better in that case:
Use my backend as proxy to store and redirect messages to the frontend
Stream messages to backend and frontend to avoid redirection
Frontend could start observing the test at anytime and if in the first case I could just prepend messages that I would read from database, in second case I will need to handle concurrency issues in some way.
I'm stacked with writing proto files, so there is nothing much to post here. Just figured out how bulky backend service going to be if I will pick first decision, since will need to duplicate TestRunner's calls there.
Please also let me know if you see some other issues I'm going to face by picking any of those decisions. Thanks in advance!
[DUPLICATE]
Related
This is really troublesome for me. I have a telegram bot that runs in django and python 2.7. During development I used django sslserver and everything worked fine. Today I deployed it using gunicorn in nginx and the code works very different than it did on my localhost. I tried everything I could since I already started getting users, but all to no avail. It seems to me that most python objects lose their state after each request and this is what might be causing the problems. The library I use has a class that handles conversation with a telegram user and the state of the conversation is stored in a class instance. Sometimes when new requests come, those values would already be lost. Please has anyone faced this? and is there a way to solve the problem quick? I am in a critical situation and need a quick solution
Gunicorn has a preforking worker model -- meaning that it launches several independent subprocesses, each of which is responsible for handling a subset of the load.
If you're relying on internal application state being consistent across all threads involved in offering your service, you'll want to turn the number of workers down to 1, to ensure that all those threads are within the same process.
Of course, this is a stopgap -- if you want to be able to scale your solution to run on production loads, or have multiple servers backing your application, then you'll want to be modify your system to persist the relevant state to a shared store, rather than relying on content being available in-process.
Not sure of the customs for people who release production django apps but I'd assume there is some kind of protection mechanism against people who spam a view or so?
If a view did not implement caching and a user just spams the url a bunch of times wouldn't that be a bad thing?
I want some mechanism to block people by IP address or whatnot if they are repeatedly calling a view at a high rate.
I tried to use this app: http://django-ratelimit.readthedocs.org/en/latest/install.html
But it promptly does not work, or perhaps my setup is wrong (has anyone used it?).
Thanks.
Typically this kind of security would happen at the web server level, i.e. in Nginx or whatever you're using to serve your app. Think about the fact that in order to block someone's IP in your app after a certain number of attempts you'd need to record their IP somewhere and then check incoming requests against that. If it were to go in your app then this kind of functionality would best fit at a middleware level.
If you were to do this at an application level for the purpose of protecting individual views then I would probably do it by means of a decorator.
You should have a mechanism in place for this anyway, as what you've described can also be a Denial of Service attack in the right context. Some web hosts have hardware-level protection for this, so ask your host about that too.
Generally in production you have some kind of frontend server. If your application logic not coupled to the number of requests, better do this work on frontend. For example Nginx has limit_req module:
http://nginx.org/en/docs/http/ngx_http_limit_req_module.html
I have a python code that performs some fairly intense computations, and then generates a plot (png file) for display on the web. I'm using python, flask, mod_wsgi, and apache. Since the computation takes several seconds (around 10 seconds), I'd like to display a "LOADING" type image while the computation is happening so that the viewer doesn't think the server is messed up, and then the actual image when computations are complete. How can I do this from the server side (not using javascript in the web browser)? In the past I remember seeing a lot of web pages where it seemed like the server was pushing a new page to the browser (from what a recall most it was search engines on message forums). The answer to this question I believe is really an http related question, so it doesn't necessarily have to be specific to serving an image (it could be an html page), or using python, flask, mod_wsgi, or apache, but it would be great if an example could be giving for just that configuration.
Before Javascript I did implement this by generating a page that had a refresh in the HTML header, with a delay of 2-3 seconds.
This page would redisplay itself until the code generating that page noticed that the 'result' was finished then generating different HTML code (without the refresh).
<HEAD>
<META http-equiv="refresh" content="3">
</HEAD>
I'm aware that this question is a bit old now, but I feel like there is not enough information available on this topic. I was struggling with this myself to find a relevant information, so I hope this will help:
Suggested solution
There are different technologies that can be used here, but I believe the simplest would be Server Sent Events. The implementation for Flask can be found here. The last part of the documentation is really important:
Subscribers will connect and block for a long time, so you should seriously consider running under an asynchronous WSGI server, such as gunicorn+gevent
So make sure fulfil the requirement. Also, it's pretty important to understand that this approach is good if you want to send the messages from your server to the client. In case you have an external worker that does the calculations for you this method will only make it more complicated for you, since your server will have to play the role of a middle man between the browser and the worker machine. On some hostings it may even not work as expected (e.g. Heroku - still not sure why it misbehaves, looks like too many updates from the worker and are not propagated properly to the client). In case you use the same host for your app and the workers, you should have no problem though.
Alternate solution
In my opinion this type of calculations belong to background, so this solution assumes that we have some kind of workers doing the job for you (like I had when I first encountered the problem). Note that this solution is not a server->client communication, but it's based on polling. I think this may be the only option if you don't run on the asynchronous server in production.
So let's assume you have a worker which status you can check, for example Iron Worker. The user visits your page and this invokes the calculations on the worker. From this point on you should use AJAX calls to get the status update directly from your worker. What I did in my app, I used jQuery to poll the worker web api and learn about it's status. After you discover that your worker is done, you can just reload the page or just the image or whatever else you need.
Additional information
If you need to update many places at the same time (not only the browser), you can use queue services, for example ironMQ, which allows you to propagate your messages to a special queue, and then subscribe to this queue with a client and receive the messages from it. This is what I did before I discovered I can query the worker directly for it's status.
Disclaimer: I'm not very familiar with any of the things mentioned in the question title.
Would it be possible to use a browser control (like Webkit) as a frontend for a WSGI app (using a framework like Flask) without starting a local WSGI server?
Basically the requests and responses are managed by a middle layer between the HTML UI and the WSGI backend. A certain URI could mean "Local", for instance "local://" or something similar, and will be routed to the embedded WSGI app with all the original headers etc.
You will lose any features that a normal WSGI server provides unless you implement it yourself or somehow embed a server that is also usable via an API instead of real HTTP requests.
Now that I think of it, this is the only real requirement: A WSGI server that is callable via an API and not just real HTTP requests.
I know the usefulness of this is questionable (and maybe doesn't even make sense). My question is whether this is at all possible?
EDIT: Here's another way of putting it:
I want a single codebase to be both a web app and a desktop app, using an HTML frontend and a Python backend. I don't want to run a server on any port for the desktop app. What's the easiest way to achieve this?
It is in theory possible to write your own WSGI container that implements a full API and adapts that to WSGI. flup might bring some inspiration.
Earlier today I saw exactly what you're asking for -- a way to call WSGI through an API without actually connecting over the network. However, it shouldn't be that hard.
On a side note, you might want to look at PySide, of particular interest to you may be the ability to bind python elements to DOM events, so if you're just looking to trigger python code that's an even shorter route.
If you give some more detail on what you're hoping to achieve we might be able to dial it in for you.
Reviving this, since we're facing the same problem and are about to scale things up from a single view/widget to the whole app.
What I did was to simply set the base URL to something where I serve static content, and from a QRC file that's easy:
html = jinjatemplate.render(...)
self._mainFrame.setHtml(html.decode('utf-8'), Qt.QUrl('qrc:///Orsync/html/'))
For the communication, our HTML uses AJAX over jQuery for most things. You could wrap that in a layer that either does $.post(...) or api.post(...) like this:
self._mainFrame.addToJavaScriptWindowObject('api', self._webapi)
You'd need to decode the URL and create a request object yourself, but maybe that's not too hard to do? We use very few URLs currently (who are mapped directly to python objects/functions) so it's easy to do the mapping ourselves.
Data that goes back is just sent using QMainFrame.evaluateJavaScript(...), either as a direct Qt call or as a bunch of code lines fetched using $.getScript(...) (which just evaluates the code received).
I'm currently rebuilding things a bit using CherryPy, and it maps urls -> Python objects straight off, so I'm hoping there's something to be gained by that.
Otherwise, I would wish one could run QWebKit over named pipes or something similarly localized and not a tcp-socket. :)
I'm quite new in Python world. I come from java and ABAP world, where their application server are able to handle stateful request.
Is it also possible in python using WSGI?
Or stateful and stateless are handled in other layer?
Usually, you don't work with "bare" WSGI. You work with web-frameworks, such as Pylons or TurboGears2.
And these contain a session-middleware, based on WSGI - called "Beaker". But if you work with the framework, you don't have to worry about that - you just use it.
But if you insist, you can of course use Beaker standalone.
I prefer working directly on wsgi, along with mako and psycopg.
It's good to know about Beaker, though I usually don't hold state in the server because I believe it reduces scalability. I either put it in the user's cookie, in the database tied to a token in the user's cookie, or in a redirect url.
Your question is a little vague and open-ended. First of all, WSGI itself isn't a framework, it's just the glue to connect a framework to the web server. Secondly, I'm not clear on what you mean when you say "state" -- do you mean storing information about a client on the server? If so, web frameworks (Pylons, Django, etc) allow you to store that kind of information in web session variables.