So i'm a bit conflicted. I want a quality driver/library to access that is also Schemaless, but it seems the only active MongoDB library for Nodejs is Mongoose.
Now, Mongoose is great and all, but again.. it's a Schema based library, and i don't want to use one with Mongo for this project.
So, the options i have found that fit my criteria (not Mongoose) are as follows..
Mongodb Native
Probably the most widely used option, and the foundation for other libraries, but not the most friendly. The deeply nested callbacks can quickly become ugly, im my opinion.
MongoSkin
This is a decent option, and it appears to allow a lot of access to normal Mongo constructs, but at the same time it is poorly documented and not all that active.
Mongolian
My personal preference.. but it lacks access to much of Mongo's constructs, and the project seems nearly dead.. It's basically had no activity in a year.
Mongojs
Likely the most recently active between the three wrappers, but it lacks GridFS support (that i see).
Are there any other options i am missing?
edit: Adding other libs to the list..
I'd recommend you look at either:
Directly using the native node.js library mongodb-native (upon which all these are based).
mongojs, which minimally wraps the native library to emulate the official mongodb API as much as possible.
Related
I am quite new working with nodejs, I need to make a REST API that can work with websocket. I was searching for a framework that I could work with, I found actionhero.js, I think that can fit my needs.
But I see a little problem with this framework, that I can't find information about how can I make it work with oracle database, I will be really grateful if any of you can give me a light on how can I make it work this framework with a Oracle Database, or suggest me a framework based on REST API that can fit my needs.
Thank you.
Actionhero is, as you point out, a REST API framework. It doesn't include any database drivers (other than for redis, which it uses for cluster communication). You can easily ad support for any database you like in an initializer.
There are also plugins which add database support. For example, the ah-sequelize-plugin adds support for the Sequelize ORM, probably the most popular node.js ORM. Sequelize doesn't support the Oracle DB out of the box (very few things do), but there exist drivers you can use: https://github.com/adeo-proxideco/sequelize-oracle
We can accept 20 times slower to avoid using python or C++ in our project. Are there a native module that still works?
There is no need to invent wheel. mongodb package is the simplest one
But if You insist there are many ways:
Easy way: You can use Rest API of mongo and do requests to it using request package
Moderate way: Open mongodb-core package and copy out what You need most, make Your own mongodb class.
Moderate way #2: fork mongodb package, manipulate it and save with new repository name
Hard way: If You want go hardcore (: read mongodb protocol and operate with it using net package to open socket connection to mongodb server.
How about Crest? It's a node wrapper around the MongoDB server that provides a REST API. With it you could talk to MongoDB over REST instead of with a native client, similar to CouchDB.
There are some other utilities listed here. Maybe you're okay with using Python outside of your app but in front of MongoDB to provide the REST API? If so then maybe those are some alternatives if you don't like Crest. Haven't used it myself so I can't vouch for its quality, but it is listed on MongoDB's own list so hopefully it's decent.
What is the optimal way to perform CRUD operations when using Node.js with MongoDB. Can I reuse the same queries that work on mongo shell? What advantages does a ODM like mongoose provide? Any other ODMs which fit into the mean.io stack?
vmr.
Well, I guess it depends of what you want to do.
Lets take what Mongoose says in their website:
Mongoose provides a straight-forward, schema-based solution to modeling your application data and includes built-in type casting, validation, query building, business logic hooks and more, out of the box.
Resuming what I understood of that it helps you to model your database and helps you to mantain your logic organized using model like in an MVC. It's a very mature ODM and very recomended for using with MVC.
In my personal experience I started using Monk, which did the trick for a while, but the I started to need to use aggregate and other stuff that apparently Monk can't handle. And I don't wanted to tie my system to an model because is a very mutable project, so I started using Mongoskin which is, at least for now, perfect for me because I can use pratically the same query that I use at Robomongo (Which is like a Navicat, PgAdmin, PhpMyAdmin but for MongoDB) in my ExpressJs code.
Mongoose is saving your time by mapping the JavaScript Data objects to the MongoDB database.
MongoDB and NodeJS Integration
I'm reviewing various frameworks for node.js and I'm just now testing Sails.js by writing a small CRUD app. I would like to know if there is an elegant way to use a different ORM other than the one sails includes.
I haven't seen anything in the documentation in Sails.js for using a different ORM. Are there any "integrated" non-orm specific features that I may be missing by attempting to use a different ORM?
Waterline should be considered a core part of sails. There isn't any easy way to replace it with a different ORM. In the google group for Sails.js, Mike McNeil (the creator of sails) acknowledges that Sails is not currently built to support swapping in a different ORM[1].
"[...]I'm totally open towards efforts to extend Sails to support other ORMs[...]"
[1] https://groups.google.com/d/msg/sailsjs/jmR36bD-Zys/-F0ZFy1Q1IoJ
In the upcoming v0.10 release of Sails the hooks and generators have been broken out and can easily be replaced to support whichever ORM you would like to use.
The community will be able to write ORM-loaders to replace the Waterline ORM loader and a generator to generate models in the correct format for the ORM of your choice. Custom blueprint controllers will also need to be written to talk to the ORM.
It's a lot of work but something that should start to happen once a stable v0.10 is released.
I wrote up the steps to consistently disable waterline throughout sails (v0.10, v0.9.8) here: https://stackoverflow.com/a/21612024/3263412
Without replacing the orm hook you definitely loose a big chunk of Sails' features, at least until the eco system particlebanana describes is developed:
pubsub
blueprints and rest routes (but could be worked around easily)
model scaffolding
custom adapters
On the other hand i figure it would not be too incredible hard to write up an orm hook for node-orm2 or sequelize plus the facades the other Sails hooks would probably need to work properly.
I want to start testing CouchDB and Node.js but having problems to figure out what tools to use.
Can I do everything I want with cradle and node.js? Or do I need node.couchapp.js? Also is this follow application re-implementation of something cradle does too?
Some birth pains still visible as CouchDB and Node.js are both pretty new, and tools and utilities are still evolving. Relying on some random github projects is not amusing, so trying to keep these dependencies low.
cradle is for talking to a couchdb, inserting and getting documents and so on. couchapp is for something else, you can use it to put some logic (views) or even entire webinferfaces with images and so on into the database. You'll probably need both.
CouchDB has a simple HTTP API, then you can use any HTTP client library to talk with CouchDB. Cradle is sometimes handy, sometimes not, depending on the use-case. The important thing to keep in mind is that, whatever library you choose as CouchDB client library, you can always fall back to using "pure HTTP", and it's often very easy to do: it's only JSON and HTTP.
For writing couchapps, the reasoning is the same: you can start as simple as writing a JSON with the design document and PUTting it in a db; you can use a minimalistic tool as node.couchapp.js; or you can use something more sophisticated as erica. However, under the hood, you are always doing simple HTTP calls to send and receive some JSON.