Is there a module for performing validation in core mongodb driver of node.js. Similary how mongoose does it. As I would require mongodb in a new client project instead of monoose.
MongoDB introduced validation in collections in version 3.2 -
MongoDB provides the capability to validate documents during updates and insertions. Validation rules are specified on a per-collection basis using the validator option, which takes a document that specifies the validation rules or expressions.
You can read more about it in the official docs of MongoDB here.
As far as Node.js MongoDB driver is concerned, then it will also provide this feature out of the box. No need to install any other module. You can check this official tutorial which shows you how to use the Node.js driver to set up validation.
Keep in mind one thing that Mongoose provides you with application level validation so you save on the round trip time as you don't need to go to the Mongo database to validate your data. Whereas the native validation is provided by the Mongo Database itself hence a round trip would be necessary from your application to your Mongo Database to validate the data.
Related
I am creating a progressive web app that that is using NodeJS and Express as backend, MongoDB as server, and IndexedDB for storing data locally when offline.
Currently I have defined some Mongoose schema models, and my application is suppose to fetch the data from my MongoDB server and store it into my local IndexedDB when the application goes online. Is it possible to make my IndexedDB's indexes follow the format of my Mongoose schema models, so that if I made some changes to the models, the IndexedDB's indexes will follow the changes as well.
The question is not so clear, an example would have help. But from what I understand, you want to be able to change the schema in MongoDB without breaking the documents saved in IndexedDB and you don't want to update the schema in IndexedDB each time you change the schema in MongoDB. You could use PouchDB which can use IndexedDB behind the scene and it would you to match the same schema as in your MongoDB. PouchDB integrates very well with MongoDB. Thus, if you model changes in MongoDB, when the document is eventually saved on PouchDB (IndexedDB), the document would have the same schema! For your info, PouchDB is the equivalent of MongoDB but in a browser.
I am trying out React-Starter-Kit for the first time and loving all the cutting edge features baked in (apollo/graphql-client in particular). A crucial part of any app for me is the database, and for that my understanding is the same author provides nodejs-api-starter which sets up a REST interface for accessing Postgres at localhost:5000 and has a graphql webui at localhost:5000/graphl.
That is about as far as I have been able to understand of the setup so far. I have changed the frontend code a little bit so a new Component "Counter" is loaded on the home page. I need to be able to make a new counter, fetch the latest counter, and increment decrement the counter. Write now the component just outputs the 'value' retrieved from the server at 5000.
I do not think I am accessing the 5000 server correctly, do I put the port in this url line somehow?
You can pull the repo down from : https://github.com/Falieson/react-starter-kit-crud-counter-demo
This is my first time setting up a nodejs api server, I am used to using MeteorJS which has pub/sub to MongoDB baked in. I am looking forward to the separation the RSK strategy (which seems more industry standard?) provides.
I've just done setting up the full site with Database from React-Stater-Kit, I'm also a newbie so I understand your frustration.
About this question, you don't need the NodeJS-API-Starter, it has enhanced function ( such as Redis cache ) and it's not suited for newbies. You should look deeper into the RSK, it already has the DB. If you ran the boilerplate and played around, change is you'll see file database.sqlite in your folder, it's the database. Here are the things you should learn:
Use SequelizeJS to connect the NodeJS server with database. Your database can be MySQL/MariaDB, PostgreSQL or SQLite. The connection is easy and there's tool to auto-generate Models from your database
How to create GraphQL's Types and Queries. If your queries need to search through the database, import Sequelize's models and use its functions.
Test your API via GraphQLi
Note: if you want to use MongoDB or other NoSQL, try Mongoose instead of Sequelize.
How does Couchbase Lite treat the Ottoman's ref fields when synchronising with Couchbase Server using Sync Gateway?
Trying to get myself familiar with Couchbase and after watching and reading about Couchbase Server & Couchbase Lite combination (This video, this tutorial, and official docs) I'm not understanding how Lite reflects the data models defined within the Server.
From what I see, Lite and Server are not much alike, even though both represent NoSQL databases. You define, store and work with data in - it seems - different ways. Nonetheless, the Sync Gateway is there to allow synchronising Lite with Server.
And here comes the main question - how do ref fields defined in Ottoman-based server (check Model References here) get reflected in Lite when synchronised using Sync Gateway?
Please correct me if I'm just getting the concept of refs or syncing completely wrong.
The document models of Couchbase Server and Couchbase Mobile are very similar. The main difference is that Couchbase Mobile reserves "_"-prefixed fields as metadata. Other than that, they both provide JSON documents named by string keys.
I don't know anything about Ottoman, but it sounds like 'ref' fields just contain a string that's the ID of the destination document. That works the same on both.
The thing I do know is that Ottoman uses a field name called _type in documents, which makes it incompatible with Couchbase Mobile. Sync Gateway will reject documents that contain properties prefixed with an underscore. I don't know if there's a way to tell Ottoman to use a different property name.
I'm interacting with MongoDB with several drivers including PyMongo and Node.js Native MongoDB driver.
What I noticed is that when I do fs.put for GridFS storage from PyMongo it only sets few fields including UploadDate, but when I do fs.put for GridFS storage from Node.JS it also inserts additional fields to storage that I don't need including ContentType.
That may be good practice, but I dont want this field, how do I configure MongoDB insert to ignore insertion of this field when adding file to GridFS from Node.JS? According to docs you can either set it or it will use default ContentType (content_type).
How to not insert this field it all?
Well, seems like there's no support for this feature. So I just commented stuff for fields contentType and aliases in MongoDB Driver library for Node.JS. Its bad practice, but unfortunately there's no another option for that right now.
I went through the Zza sample where BreezeJS is used in combination with an NodeJS (+ MongoDb) backend.
http://www.breezejs.com/samples/zza
In the sample there is no client nor server side validation implemented as we can do with a .Net backend.
Is this simply not possible when using breeze + MongoDb or is it just not present in the sample?
The big difference with the .Net backend is that the meta data are stored client side and not autogenerated from the server. Can we assume that something similar will be possible one day with MongoDb ?
Is Breeze + MEAN production ready or is it still beta material?
Client side validation in Breeze is not dependent on the server. You can define validations directly on the client. There are plenty of examples of this in the documentation for the other non Mongo providers, but the code is the same. In terms of metadata coming from the server, since MongoDB has no schema there is no way to return what would be nonexistent metadata to the client. The only way to do this would be if you were to also use something on the server that more strongly typed the Mongo data ( i.e. something like Mongoose). This has been a request on the Breeze User Voice.
We have not yet created a Mongo example where we automatically validate the data on the server before saving, but this shouldn't be that much of a stretch, but it will be "custom" code.
In terms of being production ready, we are still adding features to the breeze ecosystem, both on the client and the server. However, we do try to limit the number of breaking changes.