​

Concept

Triggers are the entry points to your Nanoservice-TS Workflows. They are specific events or conditions that, when they occur, initiate the execution of an associated workflow. Without a trigger, a workflow is just a definition; triggers bring them to life by starting the process.

​

What is a Trigger?

Think of a trigger as the starting gun for a race (the race being your workflow). It listens for a particular signal and, upon receiving it, kicks off the defined sequence of Nodes.

Nanoservice-TS supports various types of triggers to cater to different use cases. Common trigger types include:

• HTTP/HTTPS: Initiates a workflow based on an incoming HTTP request (e.g., a user accessing a URL, an API call from a frontend application or another service). This is one of the most common triggers for web-based applications and APIs.
• Scheduled (Cron): Executes a workflow at predefined times or intervals (e.g., run a report every night at 2 AM, perform a cleanup task every hour).
• Message Queue: Starts a workflow when a new message arrives in a specific queue (e.g., RabbitMQ, Kafka, AWS SQS). This is useful for asynchronous processing and event-driven architectures.
• gRPC: Initiates a workflow based on an incoming gRPC request. This is suitable for high-performance, contract-based inter-service communication.
• Database Events: (Potentially) Triggers a workflow in response to changes in a database (e.g., a new record inserted into a table). Support for this depends on the Nanoservice-TS runtime and integrations.
• Custom Triggers: The framework might allow for the development of custom triggers to integrate with proprietary systems or unique event sources.

​

Configuring Triggers

Each trigger type requires specific configuration. This configuration is typically part of the workflow definition (e.g., in the workflow JSON file).

​

Example: HTTP Trigger Configuration (in Workflow JSON)

{
  "name": "getUserProfile",
  "trigger": {
		"http": {
			"method": "GET",
			"path": "/",
			"accept": "application/json"
		}
	},
  "nodes": [
    // ... nodes for this workflow ...
  ]
}

In this example:

• type: "Http" declares it as an HTTP trigger.
• config.path: "/users/{userId}" defines the endpoint. The {userId} part indicates a path parameter that will be available in the Context Object.
• config.method: "GET" specifies that only GET requests to this path will trigger the workflow.

​

Trigger Data in the Context Object

When a trigger fires and a workflow instance begins, the data associated with the trigger event is typically passed into the workflow via the Context Object. Nodes within the workflow can then access this data.

For an HTTP trigger, this might include:

• Request headers (e.g., ctx.request.headers)
• Query parameters (e.g., ctx.request.query.searchTerm)
• Path parameters (e.g., ctx.request.params.userId)
• Request body (e.g., ctx.request.body.payload)

For a message queue trigger, it would include the message payload and any associated metadata.

​

Multiple Triggers

While a single workflow definition usually has one primary trigger, advanced scenarios or specific Nanoservice-TS runtime features might allow a workflow to be triggered by multiple different event types or configurations, though this is less common and can add complexity.

​

Choosing the Right Trigger

The choice of trigger depends entirely on how you want your workflow to be initiated:

• For synchronous, request/response interactions (like building APIs), HTTP or gRPC triggers are suitable.
• For background tasks that run on a schedule, use a Scheduled (Cron) trigger.
• For decoupling services and processing events asynchronously, Message Queue triggers are ideal.

Triggers are the essential starting points for all operations in Nanoservice-TS. By understanding and correctly configuring them, you can effectively control when and how your application logic is executed.

This concludes the core concepts in the Introduction. You can now explore Practical Examples or dive deeper into Fundamentals.