Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 9 months ago.
Improve this question
I read many documents about node js and MongoDB. But the regret is that I can't understand when I should use nodejs and when I should use MongoDB. If anyone here who can tell me the details, it will be very helpful for me.
MongoDB and NodeJS are two different technologies. MonogDB is a database system which gives you a chance to efficiently store documents in a database and to perform operations like data updates, or to search documents by some criterias.
Otherhand,
NodeJS's responsibilty is especially to execute your application.
Node.js is a javaScript runtime environment where you can run/execute your javaScript codes meaning it's like the grill to barbeque the turkey and MongoDB on the other hand is totally different technology where you will store your data's in mostly .json format meaning it's like the chilli sauce you can use it to your barbeque or if it's not your likeness you can choose tomato sauce instead. But if you are going to learn MERN stack then you need to learn both with react.js and express.js. Home it helps.
You are comparing two totally different things. MongoDB is a Database while Node JS is a coding environment. They are related in the sense that you can configure MongoDB in Node JS.
The thing is pretty straightforward.
NodeJs is better for high I/O intensive applications and bad for CPU intensive applications.
Use MongoDB if you have no/fewer relationships among the data you are storing. But if you have a specific structure of data that you are storing or there are some relations between the data you are storing then go for a relational database.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I have doing a lot of research about frontend frameworks and have decided that I would like to try Vue.js. However, I would also like to get a backend with real time "data updating". I have looked at VueFire (Vue.js + Firebase), Node.js and Feathers. It looks like Feathers has a limited amount of resources/documentation on using it with Vue while there seems to be a good amount of information on VueFire and Node.js with Vue.js.
What are the differences between those three backends?
What are the advantages/disadvantages of using one over the other?
What are the differences between those three backends?
Let's clarify a few things.
Node.js is, as defined on their website: "a JavaScript runtime built on Chrome's V8 JavaScript engine."
Firebase is a platform as a service (PaaS).
Feathers is REST and realtime API framework, a back-end framework.
VueFire is just a wrapper around the Firebase JS SDK. It makes calling Firebase more "Vue" like.
Vue.js is a front-end framework or progressive framework as the creator calls it.
With that said we're comparing Feathers and Firebase. It's clear what the difference is and the advantages/disadvantages.
What are the advantages/disadvantages of using one over the other?
Firebase lets you hit the ground running. You create your Firebase account/project and you're set to go with all the products it offers. You do not have to worry about setting up your own database layer, authentication/security, or anything. It's all set up and managed for you, but at a cost. Besides the money factor, you've also locked yourself and depend heavy on a third party and things can change at anytime without any say in the matter.
Feathers is a framework. It gives to tools to create your own Firebase platform. You're free to configure it however you want. You're in full control and it's free. However, you will have to setup your own database layer, security, and likely more.
In the end it boils down to your needs/requirements. It's best to make a list of your specific needs and see what framework or service fulfills those needs. It's useless to search for advantages/disadvantages as you will get opinion-based answers.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I enjoy using loopback to quickly build a REST api, with a fair amount of scaffolding. All I need to do is define my data, write any custom validations, and add any other server-side logic. For simple requirements, you can have a RESTful API in minutes. What about GraphQL?
Loopback doesn't support GraphQL. A quick websearch shows a few grapql servers like express-graphql. Is there a more batteries-included option? I don't want to write a web-server. I want a framework, but I can't find such.
I just want a functioning and stable data-abstraction layer, access control, a graphQL interface, and a solid way to connect all of these reliably. Is there a solution available already?
I would prefer a solution using either nodejs or python
It may help you to know that I have just discovered GraphQL. So maybe my question shows a fundamental misunderstanding of the topic, maybe I'm ignoring something obvious. If so, enlighten me.
Does Apollo server come closer to what you're looking for? https://github.com/apollostack/apollo-server/blob/master/README.md
express-graphql's main goal is to be a minimal reference implementation, whereas Apollo Server's goal is to be a complete production-ready GraphQL server.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
Is there a javascript only mongo client?
the node mongo driver is native, right? I can see kerberos being compiled on install. plus some places it is called "native mongo node.js client".
this page says the following
It is written in pure JavaScript and provides a native asynchronous Node.js interface to MongoDB
but that just means it has compiled dependencies, right?
it is all very confusing.
I am looking for a mongo client that does not require any kind of compilation for nodejs. does one exist?
The top end of the driver is javascript, the speed critical parts are native, or it was easier to include an established/proven package like kerberos. Note that easier does not imply lazy - it implies that no implementor has yet thought the effort justified the benefit.
Drivers are listed here and it is interesting to note that there are not even minor projects that attempt to write a javascript only solution - as one might see in, say, Java.
Many more complex/mature node packages require compiled dependencies; building node products for the target platform is standard and services like Travis make this easy.
I suggested you using mongoose. this very popular.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I'm writing a npm package to import GIS data into MongoDB via mongoose. I've written unit tests using mocha to test the data transformations that happen BEFORE the mongoose model is saved.
I'd like to be sure that all the mongoose data got saved correctly to the database (including any updates that needed to occur). What would be the best practice, in this case?
My intuition create a test collection, insert all the records, ensure that it looks the way I expect it to look, and drop the collection.
Yes, setting up and tearing down all the collections in the database is necessary for ensuring there are no side effects between unit tests. In practice, this means a beforeEach() where you reconnect to the database and drop all collections, and an afterEach() where you disconnect from the database.
Some deeper information: What you are trying to do here is integration testing, where you are testing the actual integration between your code and mongo. Unit tests are tests that never call the database or other resources. More info on this here: What's the difference between unit tests and integration tests? For me, I separate them into tests/unit and tests/integration.
I'm not aware of any packages or libraries that do this for you, but take a look at this tutorial for one way to go about this.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I mean, can you use couchDB for:
CRUD of items, users
bids and auctions resolutions
bidirectional califications
forum
items comparison
You could try to use CouchDB for an application - as to whether you would be successful is another question.
Something on the scale of eBay will have special requirements that are not representative of a typical application, If you are building a small auction site then perhaps CouchDB would suffice. A document-oriented database like CouchDB may not be so hot when you have to deal with transactional/records-based data like that associated with auctions.
I think couchdb would be excellent for part of the problem, though there are a few elements that would not be great. Particularly, eventual consistency over distributed nodes seems really bad for real time bidding.
You could keep the the item and user info in CouchDB, along with forums and a lot of that sort of stuff, but some functionality (bid tracking, search) would be more suited to other backends. As an example, the CouchDB guys are looking at tying CouchDB into other tools (like SOLR) for indexing, etc.
I would look to see how Amazon uses SimpleDB internally (or do they?). Might have some clues as to right ways to use a document-based database.
As you can see here they are indeed using non-relational approach, so I guess you're heading in a correct direction (flexibility-wise at least).