What setup do you use for localization in your nodejs/express app?
Right now I'm using i18n-node in my project. But I'm not happy with the storage in the json files. I'd like to have the translations stored in a database.
I found a promising module named dialect. It can store the translations in mongodb and there's also a module from the same author which enables you to manage the translations via a webinterface(dialect-http).
Unfortunately the dialect module doesn't seem to work with latest stable versions of node. The problem is known for 2 months but since nothing was updated since then I guess the module isn't actively maintained anymore.
I think using a redis db for storing the translations would also make sense. I don't know if there's an module for that.
Maybe you guys have some hints or know of any good modules?
Why don't you just fork i18n-node and overwrite the read and write functions with your own persistence mechanism?
https://github.com/mashpie/i18n-node/blob/master/i18n.js#L235
It seems like you could easily persist the json data within a redis key instead of a json file with a few changes.
I could suggest you to use lingua. Here an example =) http://www.jmanzano.es/blog/?p=647
Another option to lingua might be http://i18next.com/node comes with backends in redis, mongodb or couchDb (and Filesystem of course!)
Related
I have some node.js code that connects to CouchDB and now I'm exploring other NoSQL databases (DynamoDB, MongoDB, etc).
Is there a DB-agnostic module that would allow me to switch NoSQL databases without much trouble?
For sure you will need to change your code to adapt to a new database.
Anyways, there are a few options that allow you to switch from one of other database easily.
If you consider building from scratch, Loopback has a juggler that allows to setup each model to connect to a different database. If you want to include it as a module in your app. probably you are looking something like Waterline.
I have only used Loopback, it's great.
I haven't used Waterline.
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.
I can't find any information on initalizing a couch db. What's the best method of initializing and creating the map and view functions for couchdb at deployment?
I have a node server which will access a couchdb. Should I just create the http calls necessary to create the proper logic on couchdb from my node server or is there a better way handling the initialization of the db?
EDIT: Also is there any good open source projects that I can take examples from?
I'm not sure your question is clear. Remember that CouchDB is schemaless, so, at startup, there probably isn't anything (ie, documents) on which to base view functions.
If you mean a helper to setup a design document with attachments and the like, in addition to the other answers, have a look at Kanso (http://kan.so). If you're comfortable with Node, you'll find it friendly.
If, on the other hand, you're looking for something to analyze existing docs in a CouchDB and guess at good views, I've haven't come across that yet.
One possibility would be to use erica.
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.
I am developing an application with Express. I am using memory to store sessions at the moment. However, I would like to store them in mongodb.
I know I can just develop a store (it's just 5 functions). However, I was wondering: is there a good library to do that? I installed connect-mongodb, but apart from the fact that it has ancient versions of connect, bson, mongodb etc. as dependencies... I was wondering what the "current" established way to do this was.
I just found connect-mongo too (just to add to the mix).
Hints?
Merc.
I touched on this in an answer to your other question, but older versions of dependencies don't necessarily mean a module is broken; if the module works with your version of MongoDB and has its own tests that pass, it's very likely it's fine (though it is sometimes worth determining if old versions of modules it depends on had dangerous bugs).
If you decide you don't want to use the module due to the outdated dependencies, you might also look into other modules that are more up to date; at a glance, connect-mongodb might be a candidate.