I have questions regarding stored JavaScript Procedures. After reading the Blog Entry from PointBeing, I have some questions.
Is there an advantage to storing my code in the DB? I mean functions like lookups for documents, not adding numbers like the example from PointBeing.
Is MongoDB stored javascript faster than node.js javascript?
Is MongoDB stored javascript queries cached and are they any faster?
I'm interested in MongoDB stored javascript performance compared to Node.js Javascript.
Evaluating functions stored in db.system.js ("Stored procedures", when you would like to call them that) is deprecated. The articles on the db.eval shell function and the eval database command have a "Deprecated since version 3.0" warning and the article on server-sided javascript doesn't mention it anymore. So you should avoid using it. One reason is that you can not run a javascript function when you use sharding. So when you build an application which requires eval, you prevent it from scaling in the future. Another is that javascript functions undermine the permission concept. They always need to be run as admin, which makes it impossible to establish a sane permission system. This is especially problematic from a security standpoint considering that server-sided scripts which use user-provided data can potentially be vulnerable to arbitrary script injections.
The advantage of server-sided javascript is that it runs on the database server. This reduces latency between application server and database server when you need to perform a large number of queries. But you can get the same advantage by opening a mongo shell on the database server and executing it there.
The latency advantage is only relevant when you perform multiple queries from your script. When you have only one query, you will still have the latency when invoking the script. So you gain nothing except unnecessary complexity.
There is no additional caching or other optimization for server-sided javascript. Even worse: It will get reparsed and reinterpreted everytime you run it. So it might even be slower than javascript in your application server.
Further, many complex queries which would require script support to implement only with find() can often be expressed using aggregation which will in most cases be far faster than doing the same with find() and javascript because the aggregation framework is implemented in C++ and has access to the raw BSON documents.
The hilarious thing is that blog post ( http://pointbeing.net/weblog/2010/08/getting-started-with-stored-procedures-in-mongodb.html ) was written when JS only took single threaded global lock.
That means there was no con-currency features or more granular lock associated with it (the lock still being a problem and con-currency is only achieved through multiple isolates still). Just because you see it in some random blog post does not mean it should be used.
To answer your questions directly:
Nope. In fact the disadvantage is that the calling user needs full admin rights. This means you give every single privilege to your web user since the inbuilt JS enigne has hooks for everything, including administration functions as such it requires admin rights in order to run.
Calling JS from JS to JS to C++ in JS? No
No, MongoDB caching does not work like that. I recommend you read the fundamentals documentation: http://docs.mongodb.org/manual/faq/fundamentals/
Related
I have been using JS for simple front-end scripting for a while now, but am absolutely new to Node.js. After some surfing, I found out certain stuff about Node.js that it is fast, event-driven,uses modules, can be used both on server and client side, can be run from command line, etc.
As a project, the following task has been given to me:
"To develop a graph algorithm (such as minimum spanning tree) in javascript using node.js. Use the larger of the following graphs as inputs: http://snap.stanford.edu/data/ " [the link contains data from various network sites organised as nodes and edges and stored in .txt files]
Now I know how to implement a graph algorithm in a language (such as C), can even do it in JS using arrays. But I need some help regarding the "using node.js" part of the problem. What is its purpose in the problem ? Which of its features should I look up ?
Typically JS was made to run inside a browser.
Node.js is actually a javascript runtime invokable. You can invoke it from commandline. This means you can execute files of code from commandline like many other languages which you might be already familiar with. Beyond, that there is nothing much from your context.
But, yes it is fast, event-based, async and like server-scripting languages has server-handling capabilities inbuilt. That said it can be used for non-server contexts as well. Like computation in your case.
Node JS helps you to run backend logic, which is written on Javascript Language.
For example, in PHP, when you write backend code, you need some kind of application which will get all clients requests and run specific code to handle it. In PHP it will be done via Apache Server. In Java it will be done via Glassfish/JBoss/Tomcat.
Node JS is something like them, but for Javascript code.
I am developing a client-side javascript application (to run in google chrome) which needs to load a large amount of data from disk, and currently this is creating a huge bottleneck in speed, enough so that it may render the application unviable.
I was wondering if it is worth looking into building an NACL plugin to solve this problem (ie: using nacl_io)?
Should I expect reading from disk using an NACL-based solution to be significantly faster than javascript, and if so, what kind of speed up should I expect (ie: 2x, 5x, etc)?
I don't know enough about javascript's internal file readers, nor the specifics of NACL's pipeline for that matter, to answer these questions myself.
Native Client connects to the same underlying Chrome interface as JavaScript when reading files, so you likely won't see a significant speedup. In addition, if you read the data in your Native Client module, you'll need send it to JavaScript afterward anyway.
That said, perhaps you a reading from the disk inefficiently. Try reading from the file in larger chunks (experiment with different sizes: 64k, 1m, etc.) if you aren't already.
There are two reasons you may want to use Native Client anyway:
If you can also process the data in the Native Client module, and the processing is currently CPU-bound or can be parallelized. Native Client supports threads and intraprocess shared memory. JavaScript supports threads (via Workers) but currently only allows copying or transferring ArrayBuffers, not sharing them.
If you are locking up the web page because your JavaScript code is not yielding in the event loop, you can use Native Client to read the file from another thread. You can block a worker thread in Native Client without stalling the entire app.
I would like to make some calls to a url from a mapreduce in mongo, but I don't find anyway to do that in javascript except jQuery or lower layers that seem to be accessible only from web browsers
If it may help drive the discussion, I want to call localhost, a c++ server can do complicated things that I can't do in javascript (big libraries)
While MapReduce is written in the JavaScript programming language in MongoDB currently, there is not a general set of APIs that allow access to a richer set of platform capabilities.
By design, you cannot access the network (or localhost), files, process, etc. stacks of the host operating system. It's intentionally limited to just the features of MongoDB, and even that is restricted so that the MapReduce will perform optimally.
You will need to write your queries in a different platform and merge the results, or consider other database options.
No. It's a database, not a programming language.
What you can do, however, is to dynamically create your query (from c++ or another language) which would call the server or put the required data dynamically inside.
I've been looking at the API for Flattr, http://flattr.com/support/integrate/js , which has a cool way of accepting query variables for their JavaScript to load.
My question is, do most APIs use something other than JavaScript to accept these different variables for their services? EG:
Ruby on Rails
PHP
Python
Then these are parsed by the respective language and returned as outputted JavaScript to the requesting website?
Cheers
Javascript itself is totally capable of reading how it's embedded to the HTML it belongs to, by reading document.getElementsByTagName("script") and further parse/match their src attributes. Therefore, it's not a problem at all for it to further parse the query variables attached at the end, and dynamically (all in javascript, client side) load components within.
Any javascript libraries that allow you to pack the whole thing and deploy to your own web server should take this approach, since there's no server to handle the request anyways.
On the other hand, javascript libraries that are hosted on other sites that allow you to use (like YUI) MAY take the server approach like you mentioned.
In my personal experience, projects that I have worked on have used server side languages to deal with get params.
So a request might be /myjavascript.js?id=123123 The server side language would create the correct javascript for that request.
Keeping everything on the server side has the advantage of not allowing the user to see what is going on. If this isn't a problem for you, javascript is more than capable of handling different params.
In my experience it's fairly common that widgets embedded into others' sites gets their parameters by parsing them from their script tags. It makes the widget script static and self-contained and thus easier to distribute through eg. a fast CDN. Performance is important when you're going to convince someone else to add your javascript to their site as poor performance from the widget can make the entire site appear sluggish.
A better place to specify the parameters than query parameters would however be to specify them in the URL:s hash-part as that part isn't included when caches are checked and thus the script would have to be downloaded fewer times - which of course is good for performance, especially if the parameters might shift a lot.
I looking at using Javascript server side and took a look at persevere/pintura but for a novice like me, I need more documentation and tutorials and CouchDB seems to have a lot of that but is it used as a server side js tool?
Kind Regards
Yes (seconding what #Pointy said above). The JavaScript in CouchDB does run server-side. :)
Beyond that, though, JavaScript in CouchDB can do far more than just map/reduce queries. It's also used for document validation, update handling (for processing XML POSTed to CouchDB for example), as well as HTML or other markup output from either a single JSON document (using _show) or from the results of a map/reduce query (using _list).
CouchDB does not, however, offer filesystem access or TCP/IP listeners as Node.js does. Right now, the JavaScript is focused on the "shipping and handling" for the database contents (things like validation, formatting, and querying).
If you're interested in looking into options for handling things that CouchDB doesn't do "internally" (image processing, sending e-mails, etc), you might checkout my reply about CouchApp architecture options.
CouchApp's are definitely a viable option for web apps. Coupling those with replication, it's hard to beat.
http://nodejs.org/ is a great example for server-side javascript. If you don't want to write your complete webapp on NodeJS you can trigger it via the node command.
CouchDB is a database with an interresting feature, it allows you to interact via a RestFull api making it ideally suited to access over the web, either in javascript or other client environments. If you are looking for a server-side javascript development environment, try Servoy. It allows full featured server-side application development in javascript including easy database access to all major databases.
Short Answer: Yes.
Longer Answer:
There is a Javascript Engine shipped with CouchDB, which is SpiderMonkey
(the very first engine, open source, written by Brendan Eich, creator of javascript)
CouchDB's View function is JavaScript function running server side that acts as the Map half of a map/reduce operation to construct view.
Then there is client side javascript API, which can be used to communicate with the REST layer to fetch/update documents, which is also where jQuery is used by CouchDB.
More on CouchDB's both server-side & client side javascript capability:
The default engine is capable of doing many features, while package availability is limited compared to Node.js. Kan.so can be considered "NPM for CouchDB, where some packages are server side.
For example, there are frameworks like duality that try to make use of both server side & client side javascript capability to reuse code for rendering with couchDB.
More on the engine:
(The selection of spider Monkey over v8 is because for couchDB's use case the map reduce is not v8 designed for. Also include packaging, multi-threading and also historical reason v8 did not exist that time when spiderMoney is chosen) see [the mailing list] and tweet2
There is even project to port the whole CouchDB to Node.js (i.e. instead of Erlang), Chesterfield
I am glad if someone can add how Erlang talk with the javscript engine.
Thanks for everyone's answer, this is an important thing to make clear for people like me messing up couchDB with some Node.js packages
No, CouchDB is a document-oriented database that can be queried and indexed in a MapReduce fashion using JavaScript. CouchDB also offers incremental replication with bi-directional conflict detection and resolution.
http://couchdb.apache.org/
CommonJS can be used for server side JavaScript, see here: http://www.commonjs.org/
NodeJS is another: http://nodejs.org/