Reader Response: SuiteScript Modular Architecture and Naming Conventions
Created: February 24, 2021
Following up on yesterday's source control question, reader Stephen also wrote in with several great questions of his own:
One change I've been working to implement is one UE/CLI script for every record type for any client of ours. The UE/CLI contains a bare minimum call into a module/library that does the heavy lifting. As we make more customizations, we just add libraries. I'm toying with the idea that "business logic" goes in the UE/CLI script and the nitty gritty details go in the module. So, a UE script would load in a module for each feature. I think this is what you were getting at with your comment, right?
This is precisely what I was getting at with my discussion of a modular software architecture. Entry points should be thin, meaning they do not contain much - if anything - in the way of processing, logic, or decision-making of any kind. Their only job is to delegate processing to an appropriate module (or set of modules) when a specific event is triggered. The work, the processing, the logic is contained in small, single-purpose modules.
I'd be interested to hear your thoughts on what constitutes "business logic" that should go into the entry point script and what constitutes the "nitty gritty" details that go in a module. Often I seem to end up with one function call in my entry point script and all the work in my library, but I feel like I should show more of what I'm doing in the Entry Point script. I'd also be happy to know pitfalls you see with this method of code organization too 😃.
First, we should clarify our terms; I typically call the nitty gritty details" the "business logic," so it seems we use that phrase differently. For me, Entry Points only exist to respond to events and delegate processing to appropriate modules based on the event. There might be a thin layer of conditionals to decide which module(s) get called, but other than that, entry points should never be interacting with the database or sending out HTTP requests or anything like that. All the real work should be encapsulated in smaller modules. Entry Point event handlers should read cleanly and clearly.
One drawback to combining many features in a single entry point occurs when you
start breaking up your codebase into separate repositories and SDF projects. If
you use an approach like I do where repositories and projects correspond to
customization features, then you need to decide where these common entry points
live, as one entry point may reference modules from multiple projects.
Generally, I create a separate repository and project for the "NetSuite Core"
for the account, and I use the dependencies in the manifest.xml in the Core
project to reference any files from other projects. If you only have one repo
and one SDF project for an entire account, then you don't need to worry about
this.
Regarding naming conventions for files too, I'd be interested to hear your thoughts. Does it make more sense to name a script, for example, "Client Name Record Automations - SO - UE" or to change Client Name to My Company Name. I'm coming from the later and moving toward the former.
My convention for file names is:
clientAbbr_projectAbbr_recordType_scriptType_feature.jsfor entry pointsclientAbbr_projectAbbr_feature_description.jsfor supporting modules
In practice that looks like:
sd_SMA_MR_Sync.js(Map/Reduce entry point for SMA sync process)sd_SMA_Sync_Parsers.js(Parsing logic used by the Sync MR)
Generally, the name for the Script Record is similar, without the Client
Abbreviation, with spaces instead of underscores: SMA MR Sync
My sincere thanks to both Stephen and Eric for sharing their questions.
HTH
-EG