Looking for opinions on this technical architectur...
# suitescript
c
Looking for opinions on this technical architecture / pattern. The requirement was to make the original client script code run when an integration saves a record. I decided to refactor the existing client script into a shared module so the newly created UE script and refactored client script can use the same logic/business rules. This keeps the logic in one place (DRY). I've been told I should have made this simpler by copy/pasting the client script code into a new UE script instead because "shared modules are harder to understand for new devs that join the team". Any thoughts?
a
just be aware that some N/modules won't work or work differently client side vs. serverside as for "its easier to understand" or whatever? no I don't care how junior you are you need to know about libraries, if you don't? congrats today I teach you!
this is like software dev 101, whoever is arguing the other side of this is a moron
1000000 1
💯 1
btw its hilarious that you made flow chart for this 💀
s
Yes this is 100 the smarter way to go to keep your code dry
c
Appreciate the differences in N/modules between script types. This only needs N/record for the UE side of the workload, the client script doesn't need any N/modules. As for the diagram, architect 4 life baby!
b
your new dev training is not going well if they require all the code to be in one file
☝️ 1
s
Or it's some project manager who makes you crazy
e
I'd back up your approach as well.
"shared modules are harder to understand for new devs that join the team"
I'd personally not dismiss this comment, and would press for more evidence or the deeper reason behind it. Unless all of your code always remains in one entry point file, then there must be a point where those "new devs" figure out multiple files. There is more likely a different objection underpinning this one, and that "real" objection should be uncovered and discussed on its own merits as a team.
👍 4
s
What do you use to draw above ?
r
You are 101% correct on creating a shared library. The other person arguing might not be understanding it properly themselves. Lack of training / knowledge. Extra marks for the flow chart lol.
s
Personally I would put the shared module actions in a suitelet. Then it can be called from both client and uE scripts. Bonus is it can redirect the user to the new transaction if userinterface context.
and therefore no permission issues or module limitations
b
the suitelet option is a terrible choice for shared code for serverside scripts, it involves an externally available suitelet. You are adding an http request and creating an external url where none existed before
2
👍 1
s
i make those suitelets dual purpose... call as suitelet from client side, but UE calls as a direct function. no external url
also extends the timeout beyond 45 sec
Copy code
let isSuitelet = ctx && ctx.request ? true : false;
let params = ctx && ctx.request ? ctx.request.parameters : ctx || {};
then include the suitelet file in the UI define
s
The comment around everything in a single file suggests there may be room for improvement with your IDE and dev tools. It should be just as easy (if not easier, due to smaller, cohesive files) to navigate a solution across multiple files as it is a single file.
c
In their tooling, not mine.
s
sorry, meant 'your' in a generic fashion; if your individual environment makes multi-file trivial/preferred maybe you can help them adopt better dev tools. I can see multifile being a pain if I were doing something like editing scripts in the NS UI 😧
c
We can't use webstorm, we can't use SDF, we've been trialing SALTO for over 5 months (still not adopted), we can't use moment, lodash, or TS... the list goes on.
I've given up trying to make the horse drink.
s
Ah, assume you're in a consulting role and this is a client?
c
Yup
s
I usually try to emphasize that it's exactly this sort of expertise and knowledge of best practices that they are paying for. If they view you as just a coding monkey I'd look for a different engagement; one that actually wants to get more bang for their [consulting] buck.
c
This contract is specifically for me to be a cog in a machine.
s
ah, well then be the cog, or join a different machine.
c
Indeed.
s
sounds like the current machine is at least a bit faulty 🙂
s
sometimes companies are scared to give out their login to their prod system but I have a way through GitHub that you would never see those credentials and can use SDF local ---> your forked repo ---> pr to company github ---> inside company repo github actions --> prod NetSuite
s
that sound nice, but entirely unrelated to this thread? In any case, there's also a product for doing this and much more called Salto
s
true true
c
This situation is wild. I would just walk away at this point. They have you handcuffed for recreating the wheel(s) and instant code debt through bad design.