How ServiceNow is updating it’s Tech Stack and is using GraphQL

One of the biggest complaints ServiceNow receives is that it is running on old technology. It is true that most of ServiceNow is running on Java, Jelly, AngularJS, which comes with poor performance, but ServiceNow is working to change that.

If you want to deep dive how to customize SN Components via new Tech Stack – read this article.

New ServiceNow features introduced in Madrid and enhanced in New York comes with more modern technology stack.

  • The core component of newly designed pages is not a Jelly UI page anymore (it still is for Service Portal – $sp.do), but it is done with modern JS frameworks like React or ServiceNow JavaScript UI Framework. That means no Java and no Jelly.
  • To access other specific components, there are at least 50 new OOTB undocumented REST API’s to perform ServiceNow functionality which was only possible by old school HTTP requests only (history, favorites, breadcrumbs, filters, date, impersonation, UI action, etc.). This means almost all the required functionality is accessible in the front end.
  • However, not everything is upgraded to new stack yet, there are still some iFrames that call Jelly pages and some REST API’s are missing. Those too can be called using REST API’s, but it’s complicated.
  • More API’s and more components are coming to ServiceNow. A lot of performance optimizations happen when you move away from Java and Jelly.

But the natural problem arises: if we have so many different REST API’s to call to fill our page with everything we need, it becomes too complicated to continue developing and grow. We need some way to perform BATCH REST API operations.

Here is where GraphQL comes to ServiceNow.

As REST replaced SOAP, it is believed by some, that GraphQL will replace REST due to handy benefits:

  1. You only call one endpoint to get all the date instead of calling many – you do not need to call 20 different REST API’s to get all information into one page
  2. You only get the data you ask for and not what REST API developer wanted you to get – you only get what you ask for, so you can limit the transaction size to be as little as possible – hence performance increase

It iIt is also possible to use GraphQL for your ServiceNow integrations and ditch REST API’s.

  1. You only need to call one endpoint with POST for everything you need.

/api/now/graphql?api=api

2. All the parameters are in request body.

How do I call ServiceNow using GraphQL?

For example, if you wanted to get encodedRecord, sys Id and record values for specific incident:

We can also retrieve any other elements from the page (related lists, UI actions, formatters, etc.) or perform GlideRecord equivalent operations, like  isValidRecord, lastErrorMessage, canReadRecord.

To get all incidents, it looks more complicated, but way less complicated than the old way. Remember this is all done from client side and you have access to anything you ask for.

Also, as this is fully undocumented yet, I haven’t spent much time around to find the ideal queries. This probably could be optimized a lot.

What are other tools in ServiceNow to support GraphQL?

1 ) You can debug GraphQL execution by opening “Debug GraphQL” module. Session debugger was greatly enhanced with New York release, but is possible in Madrid as well the same way you debug service portal. More can be found here.

You can do some ‘mouse clicking’ in ServiceNow UI while session debugger is running and copy your GraphQL queries.

2) GraphQL subscription feature might enable you to build modern pub/sub message queues for client-side application solutions. Same as for AMB and AngularJS record watchers you could define subscriptions (ServiceNow calls them ‘Channel Responders’). With GraphQL you can do the same by utilizing sys_rw_amb_graphql_action table, which extends sys_rw_amb_action.

3) All transactions using GraphQL have “Batch REST” type and cannot be tracked separately. Logging can only be enabled at node level enabling advanced REST debugging.