Understanding Freshworks App Context

In this section, we delve into the unique context of Freshworks, introducing you to the terminologies and concepts specific to the Freshworks app ecosystem. Gain a solid grasp of the foundational elements that underpin app development within this environment, setting the stage for a deeper understanding of how Freddy Copilot can assist you.

Freshworks Terminologies

Let us explore the distinctive language and terminology used within Freshworks to navigate the intricacies of app development. We'll demystify key terms and concepts, ensuring you're well-versed in the language of the platform.

In Freshworks App development ecosystem, we provide developers with range of options and tools to build you apps quicker that adheres to Freshworks standards. They are listed as follows:

  1. App placeholders : On the Freshworks Product UI, an app can be rendered in multiple locations (pages). When you configure the app manifest, in manifest.json > product.<product-name.>location.<placeholder-name> , you can specify the placeholder on a page where the app is eventually rendered.

  2. App Lifecycle Methods : The Freshworks web interface is built as a single-page application. Unlike a traditional web application, a single-page app does not reload the entire page when there is a context change; it modifies only the relevant sections and passes a client object (that contains product context as well) to your app.

  3. Data Methods : It is an interface that the developer platform provides to enable your app to retrieve product data (in the form of JSON payloads).

  4. Events Methods : Front-end events are actions on the product UI, such as button clicks and changes/updates to the UI field values. Events method is an interface that the developer platform provides, to enable your app to react to front-end events.

  5. Interface Methods : Interface-methods is a mechanism that the developer platform provides, to enable your app to trigger certain actions on the Freshdesk UI.

  6. Product Events : Product events are events such as creating a ticket, updating a ticket, creating a conversation, and so on, that occur in the product on which your app is deployed. You can enable product events to trigger your app, call a corresponding callback function, and execute the app logic.

  7. External Events : These are events that occur in an external product or a third-party service. You can enable external events to trigger apps.

  8. Scheduled Events : Scheduled events are events that you can create with the purpose of triggering certain app actions.

  9. SMI Apps : Server Method Invocation (SMI) facilitates the front-end component of an app to invoke a server method that runs as a serverless component.

  10. App Settings Page : Installation params or iparams are parameters whose values app users can set when they install an app. These parameters are presented to the app users through the Settings page.

  11. Request Methods : Request method is a secure mechanism to send HTTP requests from an app to a third-party domain, without exposing any sensitive information that is part of the request.

  12. Instance Methods : On a product page, an app can be deployed in multiple placeholders. Also, an app can open certain generic interfaces (such as, modals, confirmation message boxes, or dialog boxes). The multiple placeholders and the interfaces are considered as different app instances. For synchronized app-logic processing, these interfaces must communicate with each other. Instance method is a run-time interface that enables this. Using the instance method, an app can also resize or close an app instance.

  13. Data Store : The developer platform offers two types of data stores - a key-value store (KV store) and an entity store - to persist and use data across the lifecycle of an app. The data stores are accessible through run-time interfaces.

  14. Crayons UI : The developer platform offers two types of data stores - a key-value store (KV store) and an entity store - to persist and use data across the lifecycle of an app. The data stores are accessible through run-time interfaces.

App structure

The following directories and files are created when Freddy generates an app for your use case. You would see a variation of these based on the app type and inferred data and placeholders.

Directory/FileDescription
Important:When building an app, do not modify the default folder/file names.
config/Contains the installation parameters, request template, and OAuth configuration files.
config/iparams.jsonContains all the installation parameters whose values are set when the app is installed. For more information, see .
log/Contains the files in which the app debugging information is captured.
log/fdk.logContains all debugging information, warnings, and errors generated when an app is created, run, packed or validated.
manifest.jsonContains details such as the platform version the app uses, product to which the app belongs, event listeners for the app, the Node.js version, request templates that the app code uses, and FDK versions used to build, test, validate, and pack the app, and npm packages that the app uses (dependencies).
server/ (All js files are ES6 compatible) **Contains files and folders related to a serverless app or the serverless component of an app.
server/ lib**Contains external libraries with methods that can be used in server.js.
server/ lib/ handle-response.js**Contains the method that can be used in server.js to handle the API responses.

server/ server.js**

When you build the app, replace the default content with your app logic.

server/ test_data**Includes files that contain sample payloads for the events that are simulated to .
README.mdContains additional instructions, information, and specifications.
Info:

** - Applicable only for Serverless applications/backend applications