I disagree with the assumption that you need a schema at all. I believe that 95% of the time people are using Mongoose they really don't need it because the benefits of having the schema defined like that just don't outweigh the disadvantages for what people are doing with it. If there is some critical and unusual role that verifying that data objects match a schema has in your application then maybe that is different. But you have to do that on the front end anyway and I just don't think that most systems really need to duplicate that effort in a different way on the back end.

For the vast majority of cases, databases are relatively small and simple. Your case probably isn't an exception. So let's actually take advantage of the fact that we have a schemaless database and lose the boilerplate.

It looks like you are planning on writing a ton of boilerplate code for every collection. Don't do that. Instead take a look at some CRUD systems for Node like these: https://github.com/AndrewRademacher/auto-crud Does MongoDB have a native REST interface? and/or you can add on to them for your specific needs.

I think some part of this general philosophy about putting that business about adding the cars to the user object for that session on the back end is probably related to security. In other words, the assumption is that you can't just take the front-end's word for it and save a user object with whatever cars it has, because someone might be trying to hack the front-end. Again, for the vast majority of cases, I just don't see this as a sensible assumption.

I think it will be much simpler if you just have some generic ways to do CRUD on the back end and just add the cars to the user's data object on the front end. And you can do fine-grained security on the back end on top of a generic CRUD system if you actually need to (i.e., there is a valid business justification, like something that affects the bottom line).

Mainly that stuff is a holdover belief system from when almost all databases were SQL-based and had rigid schemas with static languages on the back-end, so you almost had to use a bunch of boiler-platy code or rely on metaprogramming that was tricky with static languages.

I think that in 95% of cases, now that we have things like JSON and dynamic languages, it is wrong to have a bunch of boilerplate that is just differentiated by entity and sometimes field names.