[mylife] Developer best practices - Too much Client Side scripts

[david_legrand]

Hello world,

I was away from the community for quite some time. Just want to post a little message to all the new developers.

ServiceNow is a great platform (you probably already know that ), extremely agile so you can implement requirements in multiple ways and that's GREAT but the platform agility also requires to understand the platform and to take the best options for performance/scalability/upgradeability.

I have been involved recently as a fireman in a project to fix issues after a complex go live. Probably the project involved some completely new consultants and the architect / senior consultants weren't enough present to guide / help / check / validate the work of these new consultants. I don't blame anyone because I think the customer and the partner should share the responsibility but the project organization failed somehow.

So, on this instance, I was seeing client scripts, like everywhere. Yes, client scripting is simple to understand (specially for new consultants), yes it did work on the development environment where 10 users are connected and yes when you understand one way to perform things, you want to reuse this knowledge again and again.

But it doesn't mean you have to perform everything with client side scripts (client script or UI Policy).

What is the impact on the performance? Please remember that the client script has to be transmitted over the network to the user browser and is executed on the browser... So unless if you are linked with a direct fiber channel between the server and your own laptop which has a lot of CPU / RAM, the client side script will always take more time that server side scripts

When to use the client side script? ONLY when the user has to see something changing on the screen before saving and try to challenge the requirements to make most of them "after the user has clicked on save"

For example, you do NOT perform security requirements with Client Scripts. Alright, in 0.0001% of the cases you might but globally if you have the word "restrict" or "security" in the story, you do NOT use client side script.

==> If you do, think of me going on your environment, opening a list layout and bypassing your security rules by double clicking on the cells. And please don't tell me that your answer is to disable the list edition...

Another example, you do NOT use DOM manipulation unless if you really have a good justification and you know why the ServiceNow standard API can't help you. That means the sentence "the API function didn't work" isn't a good justification because you probably already have way too much customization made in a bad approach.

And if you tell me "We don't have the time to debug", I would reply "Ask your customer if he wants to pay 2 hours now OR 2 weeks in 6 months".

ServiceNow has some best practices Client Script Best Practices - ServiceNow and you should have additional best practices in your company (specially if you work for partner companies)

I'll be honest with you guys, I have read some discussions on this community, I really fear for the performance/scalability/upgradeability and the user experience on few of these instances because some people reply "use client side script" to any question.

And I'm concerned because if WE (the developers) do messy work, then the C-Level people will continue to ask for "Out of the Box" implementations and the ServiceNow vision will be completely spoiled...

Conclusion: Client side scripts are really useful in specific cases but use them only for these cases and not as a default way to implement and when you have a doubt, ask the architect or a senior consultant who has to help you. And if you do something wrong the architect / senior consultant has to explain the best practices and to take the decision between asking you to redo, redoing it himself/herself or living with this piece of work

Best regards,

David

[Michael Fry1]

Welcome back from the hole. We've all been there before. If it takes 15-17 seconds for the system to come back after clicking the Assign to Me button, run away. Run far away.

[Deepak Ingale1]

Great post David.

[Deepak Ingale1]

Is there any threshold or performance bench mark (in seconds) in order to say that particular transaction has passed the "Performance bench mark". I am not asking about "absolute", but any "relative" criteria?

Lets say for a transactio, my server takes 3sec, browser takes 2sec, network takes 1sec, so overall response time would be 6 seconds for client / user.

Can I say this particular transaction has passed from performance point of view?

[david_legrand]

I personally don't think that way (I have to admit, I never used performance testing solution) but more simply:

1) What is the business requirement for this feature? Does is make sense? (functional point of view)

2) What are my technical options? (and if the platform really can't, I say "Sorry, I won't do that". Example: using the sys_audit table to retrieve data for some reports ==> no go for me)

3) Client side is only if I have this requirement of doing something when the user is working on the form while I'll try to push as much as possible on Server side

==> Do you really need to know when you fulfill the dates that the end date is after the start date or could I just abort on server side when you try to save?

==> Yes you have an error message saying "abort" because you put an end date before the start date, is it very annoying?

4) On the server side, use as much as possible SQL (with the GlideRecord) and not the Javascript (this syndrome where you have a while encapsulating with an if condition excluding half of the records because the developer doesn't know how to use complex GlideRecord)

So I can't tell "this is good perf / bad perf" for one script but I can say "due to the requirements and after challenging these requirements, this is the best option we have for the implementation".

For me, a good developer (or architect actually) has to find the balance between

1) User friendliness

2) Process friendliness

3) Platform friendliness

4) Server friendliness

5) Buyer friendliness

Or in short "I work as if I was going to the one using the process, maintaining it and paying for it for the rest of my life" (when you think that, you only take good decisions)