NestJS encourages the use of TypeORM and entities to interact with database. I have experience with Express, but NestJS, TypeORM and their entities concepts are new to me.
Previously, when I worked with Express back end, I have been using raw SQL statements (and with command line in some cases) to interact with the database (from CRUD to database deployment). NestJS can also connect to an existing database (says, PostgreSQL in this case) without using entities (completely delete entities directory).
With that said, why do we need entities? Is it necessary for a NestJS backend when I'm familiar with raw SQL? And what's a good practice for working with database in NestJS?
Do we need entities?
Nope. Not at all. You can write raw SQL with pg or any other package all you want. It's actually what I do here
Why do we need entities?
It really depends on how you're managing your database schema, in my opinion. If you're letting TypeO/Mikro/prisma manage the schema for you, then entities are useful. If you're using something like Hasura, then the migrations are written in SQL and Hasura generates the types for you (I think prisma might be similar here actually).
Personally, what I prefer doing is making my own mini-orm that deserializes and validates the data from the database before passing it back on to the client. I can write raw SQL this way, and map it to my defined types, rather than relying than on a full ORM.
Related
I want to make some test for the database on my nodejs app. I want to know the pros and cons of using mocks or SqLite to test the database.
I found this question:
Should I use an In-Memory Database instead of mocking out my Repositories?
But it didn't give much information about each of them.
For me it depends. If I'm using an ORM I will use SQLite - I assume that the ORM stuff works as expected and it's easier than mocking the ORM.
If I'm writing my own code to do database stuff, I'll mock it. If I have a database service layer, I'll mock it.
Basically, if I write it I'll mock it and if I use an ORM or library I'll use SQLite.
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.
Currently I am using the pg module. I know how to query the database
client.query("INSERT INTO users(username, password) values($1, $2)", [username, password]
But I was wondering if there's a separate module that I don't know about or a "good practice" way of doing queries with PostgreSQL on Node. Especially if there is a primary key such as a username. I tried building models such as User.js but in the models I am still hard coding the query.
Thanks
I think a much easier way of doing this is to use something like Sequelize ORM. In a nutshell, Sequelize will allow you to write all of your schemas and queries using JS objects. If you're unfamiliar with it, there are a few great examples here.
Basically, this will abstract a lot of the raw query code from your Node.js module, and allow you to write more syntactic JS to interact with your DB. It also includes promises, which will give you an easier way around the async nature of Node rather than queries nested inside each other.
If what you want is to gain any level of abstraction for your data layer, knex/bookshelf is what you want.
The best part is you can choose which level of abstraction you want.
Want/need to do raw sql queries? knex can do that for you.
Want neat query builder capabilities? knes have that too.
In need of industrial ORM lift? there is bookshelf.
Bonus: knex has a very decent migration tool, which means if you want to manage database schema versions you can do that too! Migration tools are the best way to avoid madness when dealing with real world databases.
Give it a try:
http://knexjs.org/
http://bookshelfjs.org/
Hope it helps you as it helps me!
Hey everyone I am working on nodeJS app. I searched some modules to manage my database (orientdb).
My question is: Why we use any ORM or ODM (or why is it recommenced), because there is a module which can provide many functions to manage DB.
I am still confused what should I use orientorm (https://github.com/mav-im/orientorm) or oriento (https://github.com/codemix/oriento)
Thank in advance..
Depending on the goal and depending on the ORM, ORMs have the advantage of adding support for:
schemas / models / collections: this makes it easier to create all classes/properties and, in some cases, migrations;
validations: make it easier to verify what gets saved in the DB.
All OrientDB ORM's I've seen for node.js expose Oriento, so that makes it easy to access the underlying oriento methods for doing more complex stuff.
Having said all this I recommend you try the waterline ORM with waterline-orientdb adapter. Waterline is an adapter based ORM with support for multiple databases (including support for associations between databases). Waterline-orientdb is the adapter for OrientDB which is based on Oriento. If at any point you need to use Oriento you can call .getDB() to access Oriento's instance.
Oriento is much more mature and supported. I suggest you to go with it.
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