you're from another planet bro 💯😊what you're doing now it's perfect, keep going and I'm sharing your channel even in my WhatsApp story daily 😊 I'm here to help you whenever you need 🤜🤛
An excellent tutorial like all the others. Thanks, Dave. Thanks for the advice: "Keep striving for progress over perfection". This is the key. What do you think about doing a tutorial about NextJS?
your explanations are just perfect Dave , I would have liked to know your channel before all the courses purchased here and there ... I really expect a ton of videos from you ( PHP , Symfony , Sass please ...etc ) . Thank you Dave :)
@@lavitzwind6709 yes, this series delivers the backend of the MERN stack (Node, Express, Mongo) so when combined with my React tutorials, full MERN projects may be completed. I'll be posting MERN projects, too.
Have you got videos of you setting up this project? I see everything is well documented and organized. I’d like to be able to follow along to better understand how you decide to write your middleware. What you choose to log. Why the credential check is before CORS etc.
Hi Sasha, good questions! I do not have videos setting up the project. I just make the tutorials. To answer the specifics you mentioned: I write the middleware based on need only. I only log things during development to see the values myself or during a tutorial to show as an example. The credential middleware is referencing the 'Access-Control-Allow-Credentials' which is sent back because browsers will send a preflight OPTIONS request before sending the intended POST (or other) request from the frontend. If it doesn't pass preflight, it will block the intended request. More on that on MDN here (look for 'Preflighted Request" subheading): developer.mozilla.org/en-US/docs/Web/HTTP/CORS
@@DaveGrayTeachesCode thanks! I actually did find what I was looking for since commenting. Turns out this video is part of a larger Node playlist, and I'm slowly making my way through those. Thanks! I subbed.
You can't throw out normalisation without consequences in a no SQL database any more than you can in SQL. Sure SQL database designer stress it more, but it is entirely up to whoever creates the schema to ensure there's no room for redundancies (except for keys) in that schema. More about that later. But there's nothing _in_ SQL that forces you to normalise your schema and hence data. You can store redundant data in SQL as easily as MongoDB or indeed paper files. In any case the effect of _not_ normalising is the same: potentially redundant data that becomes contradictory and therefore wrong when you edit it. Because you forgot where you put all the copies and so when you did an one or more didn't get updated properly because you forgot about it or accidentally used different data for one. Even with psuedo SQL you can normalise to third normal form and be fairly sure this just can't happen. Unless for instance you did misidentified what needs to be 'an entity', eg, you did something like hard bake all address details into your person table, because you were convinced you'd never, ever, need to consider an address as something separate from an individual person. Which is clearly not true, because people change their address all the time... A "proper" SQL implementation will give you ways of ensuring the rules YOU put in are followed, but there's nothing forcing you to put them in in the first place, and indeed in many so called SQL implementations such as MySQL for instance much of this rule enforcement is either missing or turned off by default. Except that pretty much always you have to make a special arrangement to store than one thing in every intersection of row and column, and usually all rows in a table must have the same number and type of columns. Which indeed goes a long way to explain why MySQL is considered so fast compared to other RDBMSs (relational database management systems). Purists might argue it's because it dosen't qualify as an RDBMS, instead it's just a store of tables with an interpreter that allows SQL style queries. That brings me to another point. Normalisation _doesn't_ remove redundancy from your data! It replaces uncontrolled redundancy in data meant to be informative with controlled redundancy in the form of having the exact primary key of a row in a second table being referenced as a foreign key in a the first table. And the data in the first table refers to or is related to data in the second table. To find related data to the current row in the current table you do a join where the foreign key of the current row equals the primary key of the second. Actually more typically you'd have a join that returns a (psuedo) table consisting of many rows, each with all the columns of the first table and all columns of the second, but only where the foreign key of the row of the first table matches the primary key of the row of the second. There will be just one match at most per row of first table, because each foreign key only has on value, indeed, that's true of any row/column intersection, it's a singular value, AND you can't have more than one row in the same table with the same primary key. But you _can_ have one row in the second table turn up more than once in a join. Think of an address. People can share them. But we wouldn't want to _store_ it multiple times, because maybe we'd like to edit it, let's say a suburb is subdivided or renamed... So maybe we put each distinct address as a row of a table. But normalisation has a cost. Namely that if we have selected a person, we don't have address, so every time we need a join to find it. Which is slower than just printing out a person row with all that extraneous shit already stuffed into it. So often database designers will practice strategic denormalisation. And/or use a 'view', basically a virtual table that resulted from a join. Because join, queries, etc. don't usually return actual new tables, but the results are kind of formatted in a way that resembles a table except you can't typically do queries on it without generating it again. Views remove that restriction.
(node:6036) [MONGODB DRIVER] Warning: useNewUrlParser is a deprecated option: useNewUrlParser has no effect since Node.js Driver version 4.0.0 and will be removed in the next major version (Use `node --trace-warnings ...` to show where the warning was created) (node:6036) [MONGODB DRIVER] Warning: useUnifiedTopology is a deprecated option: useUnifiedTopology has no effect since Node.js Driver version 4.0.0 and will be removed in the next major version hi, Dave. I got these warnings, how to solve them? Thanks!
I would like my web server to be entirely located on my device. I have also experienced some corruptions that happen with the built in fs (file system) occasionally erasing json files. I think it might happen when fs tries to read and write a file at the same time. What would you recommend I do if I wanted everything to remain on my pc? Is there a more stable alternative to using fs? Or a way to prevent the occasional json file deletion?
I used JSON in the first part of this series, but starting at this video, I switch things over to MongoDB which I recommend. You can install MongoDB on your PC if you want.
Hello Dave! In PHP and MySQL, before each query, the script needs to connect to the database first. In node.js, if I put the connection to mongoDB in the file that runs the application (in your example 'server.js'), then I don't need to connect to the database before each query? Thanks in advance!
Yes, from the source code in the course resources: github.com/gitdagray/mongo_async_crud/blob/main/server.js You can see on lines 16 & 17 that connecting to the database is the first thing we do. Then on line 65, we listen for that connection.
Hi Dave. Thank you so much for this tutorial series. Just completed this one and was presented with an error informing me of a deprecated function: - MongoParseError: option usernewurlparser is not supported After commenting that line out of the dbConn.js file the connection works. Are there any problems that not having this line in my code will cause?
Hi Carl, technology keeps moving forward. Features will be deprecated and new ones will be added. I suggest following the info provided by the deprecation notice and all should be well.
That's like asking "How do people do things?" Of course, they do things in many different ways. So do dev teams. In general, yes, I am doing things like other developers. Will you find that some dev teams in the industry do things differently. Yes, you will. Learn what you can and realize there is never usually only one way to achieve the goal.
.env files should never be in a Github repository. They are used to store environment variables with values like API keys, database passwords, and other secrets. A .env file should always be added to the .gitignore file's filelist to insure it is not added to a code repository. You will need to create your own .env file for this tutorial. I hope this helps!
In my login system iam building i have a coconut farmer coconut collector and a buyer and after login all three of them should navigate to their respective pages (an update profile page) there is no admin so how to alternate your app to according to my reqitments dave any suggestion will help me a lot
hello sir i am working on a fullstack ecommerce website using react.js node.js mongodb .i am stuck at point of database connect can you help me with that i am using mongoose v6.3.1
I bet.
This is most precious mongodb content in the entire universe
you're from another planet bro 💯😊what you're doing now it's perfect, keep going and I'm sharing your channel even in my WhatsApp story daily 😊 I'm here to help you whenever you need 🤜🤛
Thank you so much Abdullah! I appreciate you sharing. 💯🚀
@@DaveGrayTeachesCode you're welcome dave! 🤜🤛👩💻Keep going 🤗
Thats amazing information about Mongoose: ruclips.net/video/ppdhG0TiLiw/видео.html
"testing123... kinda like a mic check". dave you are a backend rockstar
Thank you! 🎸🤘🙏
@Dave Gray
Thank you for making this tutorial simple enough for us beginner to understand better!!!
Just what i need it!
You're welcome! 💯
Your explanation is amazing! I wish you were proffesor in my college...
Thank you!
An excellent tutorial like all the others. Thanks, Dave. Thanks for the advice: "Keep striving for progress over perfection". This is the key. What do you think about doing a tutorial about NextJS?
You're welcome! NextJS is a great idea and something I definitely plan to cover 💯🚀
This was perfect! Straight forward, easy to follow and succeeded with a connection. Thanks!!
You're welcome, Judith! 💯
your explanations are just perfect Dave , I would have liked to know your channel before all the courses purchased here and there ... I really expect a ton of videos from you ( PHP , Symfony , Sass please ...etc ) . Thank you Dave :)
You're welcome! And thank you for the requests. 🚀
You've read my mind! This is exactly what I was expecting right after Node/Express. Great!
Glad to help! I wanted to cover the full MERN stack when combining this Node.js series with my React tutorials. 🚀
@@DaveGrayTeachesCode, it would fantastic if in the end, you can build MERN projects. Using all of the knowledge acquired.
@@lavitzwind6709 yes, this series delivers the backend of the MERN stack (Node, Express, Mongo) so when combined with my React tutorials, full MERN projects may be completed. I'll be posting MERN projects, too.
Have you got videos of you setting up this project? I see everything is well documented and organized. I’d like to be able to follow along to better understand how you decide to write your middleware. What you choose to log. Why the credential check is before CORS etc.
Hi Sasha, good questions! I do not have videos setting up the project. I just make the tutorials. To answer the specifics you mentioned: I write the middleware based on need only. I only log things during development to see the values myself or during a tutorial to show as an example. The credential middleware is referencing the 'Access-Control-Allow-Credentials' which is sent back because browsers will send a preflight OPTIONS request before sending the intended POST (or other) request from the frontend. If it doesn't pass preflight, it will block the intended request. More on that on MDN here (look for 'Preflighted Request" subheading): developer.mozilla.org/en-US/docs/Web/HTTP/CORS
@@DaveGrayTeachesCode thanks! I actually did find what I was looking for since commenting. Turns out this video is part of a larger Node playlist, and I'm slowly making my way through those. Thanks! I subbed.
Thank you, Dave! Please make video series about Angular :)
You're welcome! And Thank you for the request 💯
Best tutorial ever!
super we need advanced tutorial for same topic
Tank you for this video I really needed this! You did an amazing job!
You're so welcome!
Professor Severus Snape
Those are great tutorials thanks for sharing !!
You're welcome! 💯
Thank you so much for the lessons I've really learned a lot
Great to hear Dani!
Very well explain! it has been very useful!
Glad I could help!
You're my hero Dave
Thank you for the kind words! 🙏💯
You can't throw out normalisation without consequences in a no SQL database any more than you can in SQL.
Sure SQL database designer stress it more, but it is entirely up to whoever creates the schema to ensure there's no room for redundancies (except for keys) in that schema. More about that later.
But there's nothing _in_ SQL that forces you to normalise your schema and hence data. You can store redundant data in SQL as easily as MongoDB or indeed paper files.
In any case the effect of _not_ normalising is the same: potentially redundant data that becomes contradictory and therefore wrong when you edit it.
Because you forgot where you put all the copies and so when you did an one or more didn't get updated properly because you forgot about it or accidentally used different data for one.
Even with psuedo SQL you can normalise to third normal form and be fairly sure this just can't happen.
Unless for instance you did
misidentified what needs to be 'an entity', eg, you did something like hard bake all address details into your person table, because you were convinced you'd never, ever, need to consider an address as something separate from an individual person. Which is clearly not true, because people change their address all the time...
A "proper" SQL implementation will give you ways of ensuring the rules YOU put in are followed, but there's nothing forcing you to put them in in the first place, and indeed in many so called SQL implementations such as MySQL for instance much of this rule enforcement is either missing or turned off by default. Except that pretty much always you have to make a special arrangement to store than one thing in every intersection of row and column, and usually all rows in a table must have the same number and type of columns.
Which indeed goes a long way to explain why MySQL is considered so fast compared to other RDBMSs (relational database management systems).
Purists might argue it's because it dosen't qualify as an RDBMS, instead it's just a store of tables with an interpreter that allows SQL style queries.
That brings me to another point. Normalisation _doesn't_ remove redundancy from your data! It replaces uncontrolled redundancy in data meant to be informative with controlled redundancy in the form of having the exact primary key of a row in a second table being referenced as a foreign key in a the first table.
And the data in the first table refers to or is related to data in the second table.
To find related data to the current row in the current table you do a join where the foreign key of the current row equals the primary key of the second.
Actually more typically you'd have a join that returns a (psuedo) table consisting of many rows, each with all the columns of the first table and all columns of the second, but only where the foreign key of the row of the first table matches the primary key of the row of the second.
There will be just one match at most per row of first table, because each foreign key only has on value, indeed, that's true of any row/column intersection, it's a singular value, AND you can't have more than one row in the same table with the same primary key.
But you _can_ have one row in the second table turn up more than once in a join. Think of an address. People can share them.
But we wouldn't want to _store_ it multiple times, because maybe we'd like to edit it, let's say a suburb is subdivided or renamed... So maybe we put each distinct address as a row of a table.
But normalisation has a cost. Namely that if we have selected a person, we don't have address, so every time we need a join to find it. Which is slower than just printing out a person row with all that extraneous shit already stuffed into it.
So often database designers will practice strategic denormalisation. And/or use a 'view', basically a virtual table that resulted from a join. Because join, queries, etc. don't usually return actual new tables, but the results are kind of formatted in a way that resembles a table except you can't typically do queries on it without generating it again. Views remove that restriction.
Awesome tutorial thank you
You're welcome, Sona! 💯
Thanks Dave. 👍
Great tutorial 👍
Thank you! Cheers!
(node:6036) [MONGODB DRIVER] Warning: useNewUrlParser is a deprecated option: useNewUrlParser has no effect since Node.js Driver version 4.0.0 and will be removed in the next major version
(Use `node --trace-warnings ...` to show where the warning was created)
(node:6036) [MONGODB DRIVER] Warning: useUnifiedTopology is a deprecated option: useUnifiedTopology has no effect since Node.js Driver version 4.0.0 and will be removed in the next major version
hi, Dave. I got these warnings, how to solve them? Thanks!
Just had the same error, did you solve it?
@@mecklonfernandes5036 delete them, not needed anymore. Can't find any solution, but see new code bases that don't use them anymore.
The Read operations are slow compared to sql.. only write operations are faster in no-sql
I would like my web server to be entirely located on my device. I have also experienced some corruptions that happen with the built in fs (file system) occasionally erasing json files. I think it might happen when fs tries to read and write a file at the same time. What would you recommend I do if I wanted everything to remain on my pc? Is there a more stable alternative to using fs? Or a way to prevent the occasional json file deletion?
I used JSON in the first part of this series, but starting at this video, I switch things over to MongoDB which I recommend. You can install MongoDB on your PC if you want.
Hello Dave!
In PHP and MySQL, before each query, the script needs to connect to the database first.
In node.js, if I put the connection to mongoDB in the file that runs the application (in your example 'server.js'), then I don't need to connect to the database before each query?
Thanks in advance!
Yes, from the source code in the course resources: github.com/gitdagray/mongo_async_crud/blob/main/server.js
You can see on lines 16 & 17 that connecting to the database is the first thing we do. Then on line 65, we listen for that connection.
@@DaveGrayTeachesCode Thanks a lot for the explanation!
@@DaveGrayTeachesCode One more thing: in node/express you don't need to close the database connection? Or does this only apply to mongodb?
Hi Dave. Thank you so much for this tutorial series. Just completed this one and was presented with an error informing me of a deprecated function:
- MongoParseError: option usernewurlparser is not supported
After commenting that line out of the dbConn.js file the connection works. Are there any problems that not having this line in my code will cause?
Hi Carl, technology keeps moving forward. Features will be deprecated and new ones will be added. I suggest following the info provided by the deprecation notice and all should be well.
@@DaveGrayTeachesCode Thank you. Really appreciate it
can able to access the routes like register, auth from your cloned code it just display unauthorized
Yes, if you just clone the code and don't work through the course, you will miss some things.
hello dev, I wanna know that the way it industry doing things? or your own practise?
That's like asking "How do people do things?" Of course, they do things in many different ways. So do dev teams. In general, yes, I am doing things like other developers. Will you find that some dev teams in the industry do things differently. Yes, you will. Learn what you can and realize there is never usually only one way to achieve the goal.
I can't find the .env file in the starter source code. Has it been removed?
.env files should never be in a Github repository. They are used to store environment variables with values like API keys, database passwords, and other secrets. A .env file should always be added to the .gitignore file's filelist to insure it is not added to a code repository. You will need to create your own .env file for this tutorial. I hope this helps!
@@DaveGrayTeachesCode Thank you so much for your fast reply! I'm a total beginner...
Great 👏
Thanks!
In my login system iam building i have a coconut farmer coconut collector and a buyer and after login all three of them should navigate to their respective pages (an update profile page) there is no admin so how to alternate your app to according to my reqitments dave any suggestion will help me a lot
I think I would apply user roles - covered earlier in this Node.js series - and you could route based on those.
@@DaveGrayTeachesCode hi dave , can you kindly explain a bit more on this
Nice
hello sir i am working on a fullstack ecommerce website using react.js node.js mongodb .i am stuck at point of database connect can you help me with that
i am using mongoose v6.3.1
In this MongoDB series, I show how to connect to the database with Mongoose.
@@DaveGrayTeachesCode I got the solution after some reasearch thankyou sir
@@yogisha56 hey how did u fix it? i seem to be having the same problem where i cannot connect to my database. 'Error: unable to connect to databse:'
MongoDB🐍🌮🌮🌮
tf is this man talkin
{2023-10-11}