Building ServiceNow apps with React: risks and concerns

The new concept of developing ServiceNow applications using React is getting more popular. After the session about modern web development at Knowledge 19, many ServiceNow developers raised various interesting questions about tools, deployment pipeline, UI kits and libraries.

However, there is one question, which sometimes missed by developers (we are too excited building awesome apps), but it is critically important for the people who run ServiceNow development practice, architects and team leads:

What are the risks and concerns of React development in ServiceNow?

That is a fundamental question, and understanding of all pros and cons should help you to establish appropriate development practice, roadmap, pick a technology stack, and manage risks more efficiently.

Risks and Concerns

Building ServiceNow applications with React (or any other front-end framework) is in some way a new concept for ServiceNow development community. Any new concept or new technology can be scary for managers and key decision makers, who truly understand the price of failure.

In most cases, the uncertainty is caused by the lack of clarity and understanding of the potential risks. However, the fear of change should be overpowered by the excitement of the innovation. Studying the concept in more detail and obtaining a deeper knowledge would enable companies to innovate, make better products and deliver projects more effectively.

Here is the list of most frequently identified risks and concerns about React development in ServiceNow:

1. Can it break ServiceNow instance or cause performance degradation?
2. Why ServiceNow (as a company) does not say anything about this approach and React itself?
3. How stable this approach is? Is it safe to use in PROD?
4. What about security? Are there any security considerations?
5. ServiceNow developers need to learn a new technology/framework, does it take much time and effort?
6. Deployment to ServiceNow is tricky and complex, is that true?
7. It is risky to choose one particular JavaScript framework/library. We need more robust approach.

Let’s take a look at those in details.

1. Can it break ServiceNow instance or cause performance degradation?

No, unless you are deliberately doing so.

Your web application is usually packaged in one single javascript file and ServiceNow simply delivers that file to a web browser where it is executed. ServiceNow does not open or interfere with the content of the file. Nothing runs inside of ServiceNow because React application is all about client-side code (web browser). Therefore there is nothing to break in ServiceNow instance.

Of course, there is a common issue when you write bad client-side code for client-server communications. This problem is not unique, and it’s not related to a particular technology or framework — bad code in native Service Portal widgets and Client Scripts may significantly affect the instance the same way.

2. Why ServiceNow (as a company) does not say anything about React?

It does. Just from a different perspective. Some parts of the ServiceNow platform built with React (!) — Studio, Flow Designer, and even some of the out-of-the-box Service Portal widgets. So React as a technology is not something new to the platform. This topic was also brought up at the annual ServiceNow conference.

Another reason you may not hear anything specifically about React is a technical consideration. React application is just a file stored in ServiceNow, you can think about it as a ServiceNow attachment (similar to an image or pdf file), the same thing. Therefore it just does not make sense to comment on the fact of downloading javascript file (the application bundle) from ServiceNow to the web browser.

Keep in mind, we’re not limited to React, and we can use any javascript framework we want — Vue, Angular, Ember, Svelte, etc. ServiceNow, as a platform, does not know anything and does not care about the content of your application package file. Your application is a kind of a black box for the platform. The box, which should be just 1) stored in ServiceNow and then 2) delivered to the browser when a user needs to run the application, that’s it.

3. How stable this approach is? Is it safe to use in PROD?

“Create-Build-Deploy” concept of web development is an industry standard adopted by ~15 millions of web developers around the world.

Every modern javascript framework is based on that concept.

4. What about security? Are there any security considerations?

One of the key benefits of building ServiceNow applications with React is that your application inherits ServiceNow security. You don’t need to implement any additional security wrappers for client-server communications!

When a React app hosted on the ServiceNow platform, it is fully shielded by ServiceNow security infrastructure.

5. ServiceNow developers need to learn a new technology/framework, does it take much time and efforts?

Learning React is much simpler and sometimes more affordable than learning ServiceNow because there are lots of FREE courses, trainings, video lessons, books, etc.

Another great thing about React is a lot of development resources you can use when building ServiceNow apps: different IDEs, component libraries, UI kits, application templates, and much more. Don’t forget the global web development community where you can ask for help and advice — it is about 500x times bigger than ServiceNow development community ( ~15M vs. ~50K of ServiceNow devs).

Yes, it does take some time to pick up the skills, but it is like switching from a bike to a car — eventually, you will be moving faster, for longer distances and be able to reach destinations you have never been before.

6. Deployment to ServiceNow is tricky and complex, is that true?

No, it is not. There are several deployment options and it is a very straightforward process that can be manual (copy-paste the app package content or drag-n-drop js/css files) or fully automated (e.g. complete CI/CD setup on GitLab).

Once you initially set up your React application structure in ServiceNow, further deployments and updates can be extremely simple and even less risky than managing update sets.

And again, we are talking about an industry standard, which means you can use all the DevOps best practices and set up an entire CI/CD lifecycle (continuous integration and continuous delivery/deployment) for your ServiceNow applications.

7. It is risky to choose one particular JavaScript framework/library. We need more robust approach.

This is very important to understand: we do not choose a particular JavaScript framework/library, we choose a development concept.

You don’t have to pick React; you can use any JavaScript framework. React is just the most popular library for building user interfaces, and it works excellent for ServiceNow apps. What framework you choose does not matter, what matters is the way how you create and deliver your web applications.

The entire web development world today is using “Create-Build-Deploy” approach because it makes all of us technology agnostic. Instead of fitting your project into a specific technology stack (e.g. Service Portal / AngularJS) you are free to choose a framework or library which works best for your projects and development practice.

Summary

Building ServiceNow applications with modern web frameworks opens a variety of opportunities for all players on the market:

• Developers can significantly improve their skills and be on the same page with millions of colleagues from other than ServiceNow worlds;
• Companies can build ServiceNow practice more effectively and efficiently and grow much faster by bringing front-end web developers to ServiceNow.