Server-Side Module Execution


In this article, you’ll learn about server-side module execution. Server-side execution means a module executes outside of the browser. That is, the module performs its function behind the scenes on the server. To configure a server-side execute, use the Execute Module API call.

What You'll Learn

After reading this article, you’ll be able to:

  • Understand the importance of server-side execution.

  • Create APIs (application programming interfaces) from modules.

  • Configure a Remote Execute API call.

  • Understand error handling of a remote execute.

Execute Module Call

In the list of Unqork APIs documentation (, you’ll find a call for Execute Module. This is the call you’ll use to create a server-side module execution. Think of this call as a trigger. But, instead of triggering a component in the module, the call triggers an entire module.

Without using Execute Module, an application's API calls happen in the browser. “In the browser” means that all data and API calls run in Express View. Everything happens on the page that the end-user sees.

In a remote execute, everything happens behind the scenes on the server. The API calls happen in a module unseen by the end-user.

Why Are Server-Side Executions More Secure?

Running everything in the browser is not secure. If an API call runs in the browser, any end-user can open the DevTools panel. There, they could potentially inject malware and access private information. By creating remote executes, you prevent malicious actors from seeing sensitive data. That sensitive data is instead hidden, processed only in the remote-execute module.

Putting internal API calls (such as Get Submissions, Create Submission, or Update Submission) in server-side modules is extremely beneficial. These benefits include:

  • Speed: API calls happen via a remote server, easing overburden on the browser.

  • Security: Bad actors can’t access Personally Identifiable Information (PII) through the Console.

  • Easier Debugging: Creating modular API modules provides a smaller code-base for debugging.

TIP  Server-side execution enables HTTP status code outputs in API modules. To learn more about HTTP Output, visit our HTTP Status Codes article.

Creating APIs From Modules

Let’s say you have a module that sends email reminders. The module has a Plug-In using the SendGrid API. When triggered, the Plug-In sends an email. We'll call this the SendGrid module.

In a separate front-end module, you configure a Plug-In to make a Remote Execute call to the SendGrid module. When that happens, the SendGrid module executes. The SendGrid Plug-In triggers and the email sends.

When you create this type of configuration, you’re essentially building your own API call. The SendGrid module API.

It’s best practice to modularize your application so that each API call is its own module. For example, an application might have a Create Submissions Module, an Update Submissions Module, a Get Submissions Module, and so on. When you remote execute these modules, you’re calling them like you would an API.

Configuring a Remote Execute

Configuring the Execute Module Plug-In is fairly simple. The most important part is knowing the module ID of the remote execute module. Adding this ID to the Data Source URL tells the Plug-In which module to execute.

You also need to set up the module being executed so it can properly receive the API call.

Think about it like an office building that has a phone at the front desk. When you call the office, a receptionist answers the phone and directs your call. Offices have someone to take phone calls. Likewise, your remotely executed module needs a component to detect the API call.

Initializer components can serve as the module's receptionist. With a New Submission or Edit Submission trigger type, the Initializer detects when the module is remotely called. So, when the module gets called, the Initializer triggers, setting the module's chain of events in motion.

In the Unqork Designer Platform, you can find a snippet to create an API module. Look for the API Specification Snippet. You can read more about this snippet here:

Because of our security standards, all Plug-Ins in the front-end module must use the Execute Module call. There must always be a layer between a front-end module and an API call.

Error Handling

Error handling a remote execute takes special attention. When a module successfully remote executes, you’ll see a 200 OK response. However, that doesn’t mean the call behind the remote execute was successful.

Let's use the example of creating a SendGrid API module. SendGrid supports the use of API calls to send emails automatically. Within Unqork, you can trigger an API call to SendGrid based on user interaction. For example, you can set a Button component that, when clicked, triggers an API call to SendGrid. This ultimately results in SendGrid sending an email. You remote execute the SendGrid API module. The Execute Module call returns a 200 OK response. But, the email never sends. The response to the Execute Module call doesn’t tell you anything about the SendGrid call.

This is where error handling comes into play. Any API calls you create should include an error trigger. This lets you know if an error occurs in the API call. The error trigger logs an error message into a hidden field. That hidden field then comes back in response to your Execute Module API call.

TIP  To learn more about error handling, search Error Handling in our In-Product Help.