I am on Linux 32-bit machine and using AppJS for developing desktop application.
After searching for a while,I can't find a way to connect to my Mysql database on XAMPP.
Is it possible to connect or I am wasting my time searching?
Please help.
From this discussion, it seems like you can use available libraries for node to do this. Like node-mysql.
Also I think you should look into this issue.
Quote:
deskshell is the next generation of appjs. Appjs merges nodejs and
chromium's event loop. This is awesome but it means that a long
running nodejs operation will stop animations in the browser and it
means lots of other unexpected side effects. Solution is to run 2
separate binaries (nodejs and chromium) and connect them together
using the chrome remote debugging protocol. Deskshell therefore is
built in javascript rather than C++ and this makes it much more
hackable and quicker to develop. Appjs will be able to be used by
deskshell instead of chromium as the "browser" part of the application
in the future.
But I strongly suggest you look into node-webkit. It is used by apps like Popcorn-Time.
Related
I created an application in Node.JS that sends data from a local MySQL database to a MondoDB database in a Cloud.
I want to install it on my clients without them seeing the source code and not even needing to have the Node.JS environment installed. Basically I want to turn it into an executable, as is done in Delphi, then the client would only have the executable and with that in theory it would not have access to my source code and would not even need the Node.JS environment installed, just the executable being enough.
I saw that this is possible using PKG at: https://devpleno.com/hands-on-pkg. But on the other hand I saw many threads on the subject saying that this is not effective, obfuscation techniques, but all aimed at JavaScript for the web, which is not my case, so I was worried.
In my studies on Node.JS all the examples I've seen are kept in production in the Node.JS environment with the code exposed, since they run on the server side and clients don't have access.
But in this case of distributing the app to customers, it made me think, and such doubts arose.
Does Node.JS see this? Is it best suited for this? Are there any more suitable options? Or JavaScript applications, even if they're not for the web, can't be turned into executables that actually hide the source code, and if they can't, why?
I have recently started the development of an App that was intended for the web, using Express.js + MongoDB to define a RESTFull Interface, all this is coupled with an HTML5 frontend that uses AJAX to receive and write data.
The first couple of beta-testers reported that they'd not be ok with the app being a web-application and would much rather have everything on their own computer for security reasons (personal data is handled).
Now, I know that there are a couple of ways to make a Node.js application appear like a native app see Packaging a node.js webapp as a normal desktop app [closed]. I already tried NW.js but I can't seem to find an option to actually run the express.js part of the application within the limits of NW.js.
To my questions:
Is there a way to run a restful api programmed with node & express
within NW.js?
Is it possible to run MongoDB inside that container?
If both or either one are not true, is there a framework that supports
running express & mongodb as a desktop application with my app?
I would focus the effort you would put into porting your app into making those same customers feel comfortable with your security measures for protection their data in the existing web-application format.
But if you really want them to run it locally then they probably need their own Mongo installed. Instead of a full blown mongo install I found NeDB. It implements the same Mongo api's so you should be able to port easily.
https://github.com/louischatriot/nedb
Embedded persistent or in memory database for Node.js, nw.js, Electron
and browsers, 100% Javascript, no binary dependency.
I'm trying to figure out how to insert data into a Meteor mongodb database from an external native mobile application that I'm writing (specifically for iOS using Cinder, right now). I'd like events that happen on the mobile device application to be written to my Meteor app's database, so that it can be immediately displayed on a browser elsewhere.
Importantly, I need to stay in my native application on the mobile device - I can't launch into a browser. I'm a bit new to Meteor, so apologies if I'm overlooking something obvious.
Any ideas on how to do this?
Thanks!
Your best bet is to use an iOS DDP client like this one. You can use this client natively in your existing iOS app and subscribe and write back to data in your Meteor ecosystem.
DDP stands for Distributed Data Protocol and is authored by the Meteor group as an external standard for real-time app frameworks to adopt. It's a much preferred method than communicating directly with the database because you can leverage the publish and subscribe methods within the Meteor ecosystem.
The protocol is under rapid development.
I believe there will be a release shortly that will expound on the current state of DDP and the evolution of its official specification. An official spec is slated for the 1.0 release.
Note: Here is a great video overview of DDP in its present form.
Another option is to have your iOS app write directly to the MongoDB instance used by your Meteor app. You can use any MongoDB driver such as NuMongoDB. Meteor polls the MongoDB database every ten seconds so web based users will automatically see updates, albeit with a short lag.
DDP is evolving quickly, as Tim mentioned, so this option might be a little more stable.
In terms of hosting, for scalability I recommend separating your MongoDB instance from the free meteor.com site, by using a Mongo host such as MongoHQ.
And what about other cases ?
I mean browser applications ?
I've build several websites using PHP and mySQL as backend, and believe that I'm fairly familiar with both. However during research for my new website I've come across node.js and mongodb (and socket.io, since the site is gonna contain a chat).
I've decided to use node.js and mongodb to run the chat - but don't know if I should just do the entire site with those two things?
Since I'm gonna run a node server anyway should I just run another (seperate) one hosting the website? Or is that an bad idea? - is it stable?
I could do the programming in PHP and still be using mongodb - but wouldn't node be way faster?
And another question:
I've planned to use ajax to handle all the posts to the page - but since I'm allready using socket.io to the chat - should I do all my post request using that?
For the ajax I've planned to use jQuery (also for all frontend effects).
don't know if I should just do the
entire site with those two things?
If you want to learn node.js then there is nothing better than coding it.
Since I'm gonna run a node server
anyway should I just run another
(seperate) one hosting the website?
You can use existing server and run your node.js app on other free port(o). I think for learning node you don't need to have dedicated machine.
is it stable?
Even versions of node.js are stable releases, however until there is 1.0 with feature freeze there could be breaking changes to its API.
I could do the programming in PHP and
still be using mongodb - but wouldn't
node be way faster?
It most probably (and definitely) would.
I've planned to use ajax to handle all
the posts to the page - but since I'm
allready using socket.io to the chat -
should I do all my post request using
that?
I would recommend stick to MVC model and use express since you can get into lot of time consuming troubles if you would use socket.io for classic stuff. Socket.io is namely for real-time functionality and things related to that.
There are already some solid web frameworks for node.js, in particular check out Express. Here's a really good article outlining some lessons and experiences from building a node.js website:
What it’s like building a real website in Node.js
Regarding your second question, it's probably still best to use AJAX handlers and HTTP with jQuery. I'm not sure that jQuery supports callbacks over raw TCP sockets.
node.js + express + jade + stylus + jQuery is my preferred environment.
Using forever to auto restart the server I've never had any real up-time issues even when I have bugs crashing the server on a regular basis.
As for socket.io + jQuery, they do get along fine, but it's just not as natural as the express + jQuery combo. I'd stick to making ajax calls for most things.
Node.JS can still be a little wild west like, but its improving. It is a very different model from coding in php, but it is very well suited for a lot of websites. You'll probably want to do the thin server (expose a REST API and your websocket endpoints) with a fatter client using something like BackBone.js to keep interactions clean.
The big win from doing the whole thing in node is that you will not have duplication of code between php and js for dealing with the DB or any other services required by both. Node.JS is also fantastic at handling tons and tons of concurrent requests.
Good Luck
I'm hoping someone can validate or correct my conclusions here.
I'm looking into writing a small side project. I want to create a desktop application for taking notes that will synchronise to a web-server so that multiple installations can be kept in step and data shared and also so that it can be accessed via a browser if necessary.
I've kind of been half-listening to the noises about CouchDB and I've heard mention of "offline functionality", of desktop-couchdb and of moves to utilise its ability to handle intermittent communications to enable distributed applications in the mobile market. This all led me to believe that it might be an interesting option to look at for providing my data storage and also handling my synchronisation needs, but after spending some time looking around for info on how to get started my conclusion is that I've got completely the wrong end of the stick and the reality is that:
There's no way of packaging up a CouchDB instance, distributing it as part of a desktop application and running it in the context of that application to provide local storage and synchronisation to a central database.
Am I correct here? If so is there any technology out there that does this sort of thing or am I left just rolling my own local storage and maybe still using CouchDB on the server?
Update (2012/05): check out the new TouchDB projects from Couchbase if you are targeting Mac OS X and/or iOS or Android. These actually use SQLite under the hood (at least for now) but can replicate to/from a "real" CouchDB server. Another clientside alternative that is finally starting to mature is PouchDB, which runs in IndexedDB capable browser engines. Using these or using them to inspire similar port to another desktop platform is now becoming a better-trod path.
Original answer:
There's no way of packaging up a
CouchDB instance, distributing it as
part of a desktop application and
running it in the context of that
application to provide local storage
and synchronisation to a central
database.
At this point in time, your statement is practically correct although it is possible to include CouchDB in an app — for an example see CouchDBX.app which is a thin wrapper around a prefixed bundle of CouchDB and all its dependencies.
The easiest way to build a CouchDB app is to assume that the user will already have a CouchDB server running. This is easier than it sounds, especially with Couchone's hosting or a prebuilt app like CouchDBX on OS X or DesktopCouch on Ubuntu. This latter is especially interesting, because if I understand correctly it is included by default with Ubuntu these days, and automatically spins up a CouchDB server per-user when you query its port via D-Bus. Something similar could (and should) be done on OS X using launchd and Bonjour.
So as you write, you either would design your app to store data in a local format and optionally sync with a CouchDB service you provide or you'd have to build and bundle all of Erlang, SpiderMonkey and CouchDB together with your app along with some scripts to make sure it was running when needed. This is possible but obviously neither of these are ideal, and believe me you're not the only one wanting a simpler solution for desktop-oriented apps!