I want to implement a dynamic web based dash board with Python 3.x (Like Shiny for R)
Bokeh seems promising from what I have read and seen in YouTube.
What isn’t clear is when and where will I need a Bokeh server and a Flask/Django Server? Will they complement each other? Or I can work on either one? Will they both be serving the same thing?
The Bokeh server is based on Tornado which is itself a capable Python web framework and asynchronous networking library. Depending on your needs, it may be possible to simply write a Bokeh app, have it show everything you want, in the way you want. Bokeh exposes some capability to customize app appearance via Jinja2 templates. You can see an example of this in the Gapminder Demo on http://demo.bokeh.org.
However, you may have more sophisticated needs, especially around authentication and access, or have an existing site that you need to integrate into. In this case, you are probably looking at embedding a Bokeh app in another page, which might be served from Flask, or Django, or IIS, or whatever. There are two basic ways to do this:
using server_document to generate a <script> tag that you can template into your page, which will embed an app from a Bokeh server into the page
using <iframe> to embed a URL from a Bokeh server into the page
Either of these can work just fine. Depending on the sophistication of your deployment environment, there may be more "devops-y" type things to do to use a Bokeh server behind a proxy or with a load balancer, etc. The Running a Bokeh Server section of the User's Guide has a lot more information for anyone needing to dive into those details.
If you are embedding an app from a Bokeh server into another web page, the Bokeh server does need to be up and running to serve the app! How to accomplish this is a separate concern, there are a few ways you might do it:
start up as an external process, and manage with something like supervisord. You can see a full example deployment like this at https://github.com/bokeh/demo.bokeh.org
embed a Bokeh server "inside" your Flask/Django/whatever app by starting your own Tornado IOLoop. You can see one example of this technique in examples/howto/server_embed. Also, this should probably be considered fairy advanced usage.
Related
I have a API server which is written in python.
And I wanted to render my react components on server side.
So I searched the best practices and result was having a nodeJS server.
But in my thoughts, this is weird because I have to build a another server with different language. This is bad at maintainable, and maybe have an overload.
So I want to know having nodeJS server is usual. and also how do big companies do server-side rendering.
If it is as simple as wanting to use Python with React, you can use python-react to render React components.
As noted above, if you are using Flask, the templating is in Jinja2, but that isn't necessarily mutually exclusive to using React in your project.
This resource on using Flask/React may be of use to you, as well.
I have a server which runs flask with python.
Now I want to make an application which can do various tasks like uploading files, updating redis database and various other things.
Now ofcourse this could be done using html pages but since the operation could involve lots of files realtime input of data and other things it might be better to make an application and manage the server from that point rather than webpages.
do you suggest using webpages anyway or would you make an application for it?
and if I make an application should I use http or not?
sorry if this is a uninformed question but I would like to learn the best methods
You might want to look into Flask-Script. It allows you to run various commands related to your flask application easily. It also allows you to easily add your own commands to it. This way you will be able to keep your administrative code still within the Flask app, but not necessarily have it accessible via a web page.
I'm trying to learn web programming in python, and have the following project in mind: mine the yahoo finance api for instrument data, and display it in real time, as well as plot charts based on instrument data.
I already did something similar using wxpython, and I'm interested in how I would accomplish this in a web application.
My first thought was to use django and matplotlib on the server, and have the client request updated chart images through jquery at a certain time interval, but after a bit of research I came upon libraries like twisted and tornado...and now I'm confused. Would they work better for this web app than django ?
After the above rambling, my question is: what library should I use for writing the web app i have in mind ? I'm also thinking that I should abandon matplotlib, and generate the chart on client side, but I'm not sure what javascript library would allow me to do that, if any.
Few tips:
1/ Do not plot your data at backend . Instead use the browsers to generate charts.I would recommend
using jqplot, or highcharts.
2/ Yes, you can use tornado or twisted instead of django, as they are asynchronous servers, and would provide faster handling of requests.
3/ You should create a REST interface of your application, with server side only sending JSON data, and do all the UI templating and charting on client side.
4/ Backbone.js (recommended, but you can use some other MVC framework), would also prove to be helpful if your app grows too complex.
I'm writing a syndication client, with the aim being to have a client for devices, and a web site that has the same functionality. I shall develop the website using Django - this is already decided; the client shall be written in python with both a CLI and a PyQt4 GUI. I have been writing the clinet first, and it's fairly database-heavy, as everything is cached to enable it to be read while offline.
It struck me today that it would make sense to use Django models for my application, to reduce the repetition of effort between the client and the website. My question is how easy it is to seperate this, and how much of Django I will need in my client to use Django's models. AFAIK I should not need to run the server, but what else is needed? I had an idea of generating the same html for my client as the website, but showing it withing Qt widgets rather than serving pages for a browser.
Has anyone tried this sort of thing before? I'm starting on this already, but it would be good to get a warning of potential dead-ends or things that will create a maintainance nightmare...
Read up on standalone Django scripts and you'll be on your path to victory. Basically all you're really doing is referencing the Django settings.py (which Django expects) and then using models without web views or urls.
If all you're really interested in is using Django's ORM to manage your models and database interaction, you might want to consider using SQLAlchemy instead.
You'll still have to run the Django app as a web server, but you can restrict it to serve to only localhost or something. And sure, you can use QtWebKit as the client.
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. :)