Thank you for the kind words Avinash.

This code design strategy is used at my current employer. I have not done any stress testing. All I have is anecdotal stories that in the scope of proof are irrelevant. In time, I will try to provide those.

What do you mean by Handled by the platform? Do you mean by the Rhino Engine? As it is still at this level of execution time that my code works... purely during engine work, and not in charge of IO.

I presume SNow does abide by Rhino Version 1.7 R5 where scripts should execute precisely as expected. If that is the case, then it might be logical to assume that smaller, and well structure code leads to less execution times. Then a smaller stack, with lexical scope pointing to fewer objects will complete a cycle more efficiently than would multiple embedded Glides in business rules, looking about a complex lexical scope. This goes in par with SNow suggesting placing code inside Script Includes, this can't possibly exclude GlideRecords.

Back to structure... in regards to SOLID it is independent of architecture or platform as it doesnt alter platform behavior in any shape, other than time required for the Rhino Engine to complete its cycle.

When you say Architecture, I understand it to mean event driven, serverless, etc, how technologies work together to supply a business need; otherwise IO might not be fitting as the platform is still in charge of it and, I'm not creating an IO implementation, rather wrapping the GlideRecord to create a more maintainable code base. Though I do understand that badly writen code anywhere leads to more problems than server load.

Knowing that JavaScript is not altering IO leaves us to explore if the Rhino engine does behave as ServiceNow advertises it should. compilation, optimazations, transpilation, scope and execution. Execution is triggered, creating a stack from which to work, context and security identified then push and pop until the stack is finished.

This means that a stack is created by the order of execution established by the platform. Each one of my DAL Glides will be executed exactly at the time expected by the platform, regardless of location. All I've done is reduce the ticks it takes to get there.

I use this structure for everything. delivering Data Objects to the UI, web services, widgets, ui macros, etc.

Because I program for human consumption first and foremost, and dont address optimazations until the need arises, i am afforded the ability to use techniques like SOLID coupled to JavaScript industry patterns to create maintainable code.

Because of that, I know that if I ever encounter server load problems, shifting to an event driven architecture will allow me to be even faster in responding to user generated actions; such as loading a page that runs 1K after business rules creating various objects that use GlideRecords. The shift of CRUD to events would be impossible through embedded GlideRecords. So by shifting CRUD operations into the eventQueue, IO is spread about threads, drastically decreasing latency: multithreading ala SNow.

I have not have had to do this as of yet, mainly staying within the async path when asked to fix unpeformant code.

There is a plethora of industry solutions not implemented in SNow, it's as if being in the platform changed the physics of computing. I truly opine that if SNow were to have a JavaScript code evangelist in staff, current practices would cease. Their structure makes it difficult to scale and maintain. Just like SalesForce has followed the programming world into industry standard code, so will ServiceNow.