Server-Side Module Execution
Overview
Server-side module execution is a module that executes outside of the end-user's End-users, also known as Express Users, are the individuals accessing an application through Express View. In most cases, end-users are the customers using the product. browser. That is, the module performs its function on the server. To configure a server-side execute, use the Execute Module API APIs (application programming interfaces) are a set of protocols and definitions developers use to build and integrate application software. APIs act as the connective tissue between products and services. call.
Execute Module Call
In the list of Unqork APIs documentation (developers.unqork.io), you’ll find a call for Execute Module. This is the call you 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 console The DevTools Console helps you securely store, build, test, and deploy your software.. 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 Personal Identifiable Information (PII) is any representation of information that permits the identity of an individual to whom the information applies to be reasonably inferred by either direct or indirect means. 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
For this example, you might 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: https://academy.unqork.com/api-course/436010.
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.
Button component that, when clicked, triggers an API call to SendGrid. This ultimately results in SendGrid sending an email.
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, view our Introduction to Error Handling in Unqork article.
Best Practices
-
Avoid chaining several server-side executed modules. Chaining can impact performance as each module executes a separate call to the server. For example, it might require 100 milliseconds to call from the back-end to your server-side executed module. Creating unnecessary layers of chained remote executes might add extra API calls between modules and can slow your application's performance.
Resources
