Hi Xaiver,
I agree that a shared set of functions used by everyone that encapsulate and hide the schema (and ideally business logic) is the way to design software. We teach the importance of using DALs in code design and many if not most developers now take that further wrapping what you do with ‘stored procedures’ into micro-service APIs. If you are using a dynamic programming language like Javascript then you do have the option to effectively store run-time-loaded code on the server, you can do the same in python and system.js is simply a convention - the code is stored as a string in BSON after all. Load server scripts is just an obscure part of the MongoDB shell - and the shell was never intended to be anything but a test and debugging tool although we have seen some people use it as part of production, I wasn’t aware you could access it from node.
My experience of the nature an purpose of true stored procedures is very different - in my worldview they exist to ensure logic runs at and in the database server - this is important with and RDBMS where you may need to perform a number of operations inside a transaction and the overhead of the client/middleware making multiple TCP calls to the server to submit all operations individually is too much - a stored procedure greatly reduces the time between begin and commit - during which the database is having to lock things reducing concurrency. This is one reason I recommend avoiding MongoDB transactions in favour of correct document modelling - the document model was created to solve just this problem.
The other use of stored procedures is about correctness - if you ONLY give access via stored procedures you can enforce business logic and security server-side. This is less important since the advent of three tier architectures in the early 2000s but really mattered when we were all running Windows. executable applications talking directly to the database.
The downside of true stored procedures is that the work is being done in the database server - which limits scalability - by moving it out to app-servers as mongoDB encourages you don’t have that issue.
So if you are still with me - if you are building application servers that dynamically pull their code from inside MongoDB it’s cool that you are able to do so - it’s an very very uncommon pattern and I’m on the fence if it’s a good idea or not versus simply maintaining a library/module that encapsulates your logic . MongoDB really doesn’t have explicit support for it that system.js collection was intended to support in-database stored procedures back when someone foolishly thought we should have them but the nature of MongoDB means it can store source code and you can fetch and run it dynamically in a few languages.