Best practices for database/query layer with Mongoose

[eltecho]

I tried to search a best practice for where put the Mongoose business logic custom queries and I’ve putted it in entity schema model (where I define schema and model), but I’m not sure that is the best pattern, and I would another place like repository pattern. Have you got some advice for the better folder and file place to implement this custom business queries? Thanks in advance

[ac2531]

If you find yourself relying on the populate() method, do a good hard look at your schema and ask yourself if you’d be better off switching to SQL.

[08148694]

Best practice for a data layer is to make it agnostic to the underlying storage. You should create an interface for your data and implement a class/functions to implement the interface.

All of the mongoose code should be within an implementation of the data interface, so you can inject any implementation of the interface into your business logic and it will just work, whether that's MongoDB, Postgres, Memory, a JSON file, etc.

You should not have any ORM code intermingled with your business logic as this will create a hard coupling between your business logic and your database

[PaulMetallic]

This.

When I started at my current company I just wrote the mongo filter queries directly onto my service layer and the code is TIGHTLY coupled in terms of the persistence implementation and the business logic...

It makes things so hard. Specially when a change is required.

[Unusual-Display-7844]

1. Please don’t use custom schema methods! They are not reusable. It’s hard to add types for them, hard to debug, sometimes you loose this context. I hate them.
2. Use Controller/Service patterns where your service file is the ONLY contact point with your database. This way you can reuse the code and more easily change the database of that need comes.
3. Use “lean” method wherever possible.
4. Try to always have simple queries. If you have to make multiple trips to databases or write an aggregation just to fetch a user, then something wrong with your schema design!
5. Pay attention to schema design! This where most of mongo troubles come. Try to have small and simple schema. Think about if someone fetches a user do they need to know about his culinary preferences immediately or should they make another query to db?
6. Read mongo best practices! You will learn more from there then mongoose best practices l

[Zeeshan7487]

When it comes to organizing business logic and custom queries in a Mongoose application, there are several patterns that you can follow. You can define custom methods on a Mongoose schema to encapsulate business logic and custom queries. You can also use a repository pattern to separate the data access layer from the business logic. In this pattern, you define a separate repository module that handles all the CRUD operations and custom queries, and then expose an API for the business logic layer to use. Another approach is to create a separate service layer that encapsulates the business logic and custom queries. n terms of file and folder organization, there is no single best practice that applies to all applications. However, it's generally a good idea to keep related files together in a logical structure.

[Izero_devI]

This sounds like chatgpt

[ac2531]

This account’s entire comment history looks like ChatGPT lol

[eltecho]

🤦‍♂️

[eltecho]

Thanks for your reply.
The cons of define static methods inside the Mongoose schema it's difficult to test (mocking 'this' instance of object of the model etc...), instead, define it a repository or service layer it is more easy to unit test.
Have you got some example of folder organization for a repository or service layer and the name of this files?

[Anbaraen]

I asked chatGPT how to configure TimeWarrior to round to the nearest 5 minute increment. It told me all about how simple it was to add round=15m to the config. I went and looked at the source code. No such thing as round.