I've been working with web2py recently, and found it very nice to use for building RESTful web apps. However I've decided to extend my JavaScript skills a bit and tackle a more 'modern', rich, asynchronous client-side JS application. Something like Gmail, in the sense that it loads the UI up-front and then only talks to the server to keep the data in sync.
I'd like to use Dojo (used Dojo and jQuery in the past, and prefer Dojo for its structure) for the client-side stuff, but what should I use on the server side? What's the best way to get Dojo's data stores talking to a standard MySQL database? I sense that something like web2py, as simple as it is, would be overkill when it really just needs to handle AJAX DB requests. I can imagine that if Dojo could talk directly to the DB a server-side framework might not be necessary at all.
There are a few questions like "what is the best framework", whether JS or server, but I guess I'm wondering what role the server-side framework plays at all in an app like Gmail, and what is the most suitable framework for such minimal logic processing?
When it comes to RIAs (Rich Internet Applications), the server needs to be just as robust and full featured as any other web application. The biggest difference is that the rendering of templates is outsourced to clients via javascript. So the short answer is, it doesn't matter. Just use whatever server side framework you feel most comfortable with.
Related
I'm starting a project that basically is a single-page app that downloads and shows a bunch of stats (using d3.js). The data layer is Mongo-powered, served through a RESTful API, and the client app will be coded in Ember.js. We want all data to be exchanged through the API, since we also have some mobile apps in the back burner that will hook to the same API.
I'm debating on whether write the API (using Express.js or other server-side MVC framework), or just serve the API use Deployd and not using a server-side framework at all, besides Deployd. I'll provide some hints about the project characteristics:
The main feature is basically a dashboard that shows aggregated stats that are already computed and stored in the Mongo database.
User interaction is minimal, enough only to allow users to customize their dashboards, but users never upload data (other that customization preferences).
Most of the app is a lot of d3.js to create and render a bunch of graphs, which can customized in many ways.
It requires a very rich and responsive user interface.
I proposed skipping completely the server-side framework, and simply go with a bunch of static HTML+CSS and do all the heavy lifting with a client-side MVC such as Ember.js. Since all data download and upload can be handled by Deployd, a pure static site would load much faster and is also easier to scale. Also, (I think) all user-related data and validation can be done with Deployd itself.
The thing is, some of my colleagues had a heart-stroke when I mentioned this idea. So I'd like a reality check: do I really need a server-side framework besides Deployd to cope with problems I cannot foresee yet? Are the benefits of having a pure static site a good enough tradeoff versus having, say, Express.js just in case?
I haven't worked with Deployd before, but from a quick skim of its docs, it is a server-side framework. It accepts requests and respond with json. It's just oriented to APIs and json and neglects html, unlike, say, default Ruby on Rails.
The main issues I can think of that might arise due to a lack of a traditional server-side framework are things like auth, CORS, and XSS/CSRF/other common security issues. You could cater for this through Deployd if it's built in or easily added, but that may be difficult.
Looking further into Deployd's docs, I see there's a guide for users and CORS. I can't find anything about XSS or CSRF.
Currently, we have a number of GUIs that have been developed using PyQt4 and PyQtGraph.
We need to make these interfaces accessible to a number of remote users and are hoping to do so by serving the GUIs through an HTML/CSS/JavaScript Web-Application.
The link below provides a few suggestions for this task, but these seem to apply to a project that is in its initial stages of creation. I'm familiar with the development of Python-JavaScript Web-Applications using the Pyramid Server and would like to use this same method for providing users access to PyQt4 GUIs that have already been developed.
https://softwareengineering.stackexchange.com/questions/109572/can-i-create-a-desktop-python-gui-application-and-run-it-as-a-web-app
So my question is, can I serve a functional PyQt4 GUI as a widget using HTML/CSS/JavaScript?
This is hard. In theory you could use a VNC-like approach that sends an image of the window to the client browser and sends user events back to the server. This will probably have poor interactivity depending on the networking and would require a lot of server power, depending on the number of users. (For an example of this, see: https://github.com/campagnola/webqt)
You're probably better off distributing the application with something like py2exe, py2app, cx_freeze, etc.
I personally haven't tried it but you could look into Wt: http://www.webtoolkit.eu/wt/
It is a C++ framework that has a Qt flavour. It has a Java version called JWt. Hence, a Jython binding exists for us Python programmers: http://www.webtoolkit.eu/wt/other_language
It is not a direct replacement of Qt, and might need modification to your Qt code to work as a Wt web app, but it certainly seems worth it to look into.
I'm about to embark on a large project based around mobile web apps. I am going to create a mobile web app that will have multiple screens, a search system and a few other features.
I need to establish a primary framework for this application. It seems I have two options; multiple separate HTML pages, or alternatively, use AJAX to download the contents and move divs in and out of the viewport.
I don't have to worry about SEO. I'm primarily looking for good performance. I understand Stack Overflow is a site about questions and answers and this does somewhat involve opinion, but I feel that based on my criteria there should be a solid answer to this question.
I'd highly appreciate it if somebody could share what they think the best option would be for me on this project.
What I believe you're referring to by using AJAX to download the contents is commonly known as a single-page web app. These generally involve rendering data using templates on the client side and sending and receiving the data via AJAX.
For these, there are plenty of excellent JavaScript framework options, including:
Backbone.js
Knockout.js
Angular.js
Ember.js
Of these, Knockout is probably the easiest to learn (seriously, the tutorial is brilliant), but the lack of routing lets it down somewhat. I tend to use Backbone for this type of thing myself, although if I were starting over I would probably go for Angular as it's made by Google and seems to have more momentum. But try a few tutorials and see which one works best for you!
All of these offer a lot of very handy functionality for your use case, as they enable you to load data via AJAX and render it on the client side quite easily. There is a learning curve for all of them, but they result in a much more maintainable and testable client-side application. Believe me, I have tried to build such an application with just jQuery, and I would recommend you avoid it as it gets very painful, very quickly!
Your mileage may vary, but by and large a single-page web app like this should perform better than a more traditional web page because once the application has loaded, all the communication with the server is just sending and receiving JSON. It will also likely be simpler as you can use a lightweight REST framework like Slim, Sinatra, Express or Flask on the server side, and just serve up the static content on the home page, then do everything else via AJAX.
im looking forward to build RT web apps with NodeJS. Coming from Rails, I've felt in love with NodeJS and Async JS programming.
Run a few experiments with Node, and then as I search tools and resources to get used with, I got overwhelmed with the lot of stuff over there.
I found lot's of libraries and components over there, and pretty much got confused on how a large-scale well-writen and implemented RT web app should be built.
So the app will run over NodeJS, using Express framework.
I read about knockout.js, a client-side library to provide realtime stuff like automatic UI refresh, and I guess I could conbine it with jQuery.
Also, I found socket.io.
The author says:
Socket.IO aims to make realtime apps possible in every browser and mobile device, blurring the differences between the different transport mechanisms. It's care-free realtime 100% in JavaScript.
So socket.io is about compatibility.
What about backbone.js? Where does it goes to?
With so much stuff, I got shocked. What should I learn? Which modules worth studing?
Im focusing on NodeJS and Express but most books/screencasts covers old versions of nodejs. So im being guided by its official API.
Now im here asking your advice and to organize somehow all the info out there.
Correct me if my assumptions are not precise, please point me to the right direction and feel free to suggest any other module that could help on my learning.
Thanks in advance
It might be useful for you to separate the node.js server side libraries (via npm etc...) from all of the client side (browser) libraries and technologies like jquery, backbone, knockout etc... when you think about it. Even socket.io which exposes a persistent socket connection between the browser and the server (to avoid polling) does not dictate what client side technologies you use.
Focus on exposing a solid web-api ( random example ) from your server and your client technologies can be swapped, augmented etc... with no effect on the server. The only place they intersect is if you're using a view technology like Jade. It's also an option to have a pure separation where the server is just serving up the client files and your client is a thicker javascript application (using knockout, jquery etc...) calling a good server web api.
Some folks try to unify the client and server models - for example, this article using backbone and node. It depends on how much data you work with to say whether that's feasible but it does couple the client and server and makes the server stateful which can have downsides (scale out, requires affinity etc...). Personally, I get wary of that much magic (binding, state, syncing etc...). Node is about keeping things simple, light and fast. It's a fast front end network server.
My 2 cents (and some may disagree). Start with node on the server and pick your storage (mongoDb etc...). Design a solid RESTful (hypermedia) API - a good webapi regardless of the client. Then start with a basic html/css/js, maybe jquery client and add things like knockout etc... as you expand your client skills. That will allow you to replace your client technologies independent of your server as the new technology winds change (and they will).
That's the hallmark of a well designed system - the ability to replace componets/sub-systems without rewriting everything :)
Hope that helps clear up some of the fog :)
You may want to look at Meteor if you are focussing on real-time Javascript apps: http://meteor.com/
I am working on app where I need to pass messages between a C++ application and a Javascript web app.
Certainly I could write sockets code myself in either language and I have done this in the past when necessary.
What I would really like is a higher-level message posting or message queueing API that does a lot of the work for me. Does anyone know of such an API?
I have looked at ICE, and it doesn't appear to have Javascript bindings. I have also looked at Boost message queue, but it only caters for the C++ side of things. If necessary I might roll my own Javascript bindings for either of these technologies.
UPDATE: Sorry should have mentioned this before, I want to run this in a browser.
To give a more complete story what I want is a simple browser-based app that is used to configure and display logging for a C++ application.
I know there are other ways of doing this, but I am specifically interested in a high-level library in both C++ and browser-based Javascript that builds a message queue ontop of the sockets API (if there isn't one then I might consider implementing it myself and writing up a code project article).
ALSO: I'm not bothered about portability in terms of the web browser. Eg if there is a high-level IPC Javascript library that only works in Chrome, I'll be happy with that.
With JavaScript I assume that you are running it in a browser? In this case your C++ application needs to provide a webserver and some kind of JSON based webservice that you can call. On the JavaScript side you just use AJAX to communicate with that webservice.
An alternative would be websockets which might be a little harder to implement on the C++ side though.
To simply answer your question: No, there is no IPC implemented in ECMAscript out of the box.
But you actually answered you question already. If you try to communicate with Javascript that runs in a browser, you indeed should use (web-)sockets connections to pipe date in either direction. Of course you could write a simple HTTP server in C++, but I guess that is overkill and does not have the capabilitys of bi-directional sockets.
It's still some work to implement a web-socket connection in C++ from the scratch (the specs were in flux for a long time), but I guess there are some librarys out already.
If you're trying to communicate with node.js, this is an almost trivial task using real sockets/pipes.
I have found a solution that meets my needs. It isn't exactly perfect but I think it works well enough.
Some people suggested using HTTP and ajax. That turned out to be a useful idea and after some prototyping I think it solves my rather basic needs.
To be more specific I am using the Mongoose HTTP server embedded in my C++ application and I am using the jQuery ajax function to pull data from the server. The jQuery client polls the server continously for new data, not particularly efficient but I think it will do the job good enough for me.
Once my implementation is complete I'll write an article explaining how to do this in detail and then I'll update this answer.
You could try DBus, it has very simple mechanism to define, query and use interfaces, and there are some components for XPCOM and webkit based browsers (for example http://sandbox.movial.com/wiki/index.php/Browser_DBus_Bridge and http://code.google.com/p/v8-dbus/). Also DBus is opensource and cross platform.
For a server side or non-browser implementation how about named pipes?
Yes it's vintage technology and the usage depends which OS you use, but as long as your server side js environment has ability to read and write files it may work, and it fits the description 'high-level' inter-process communication.