Greengrass V2 - Signaling when moving from lambda functions to native components

When transitioning from Lambda functions to native components in AWS IoT Greengrass V2, there are indeed some changes in how the code is structured and how it responds to events. This transition can offer benefits in terms of performance and flexibility, but it does require some reworking of the original Lambda code.

In Greengrass V2, native components are more flexible in how they can be implemented. Unlike Lambda functions that are typically event-driven and short-lived, native components can be designed to run continuously or be triggered by specific events.

For handling events similar to Lambda invocations, you have a few options when implementing native components:

1. Long-running process: Your component can run continuously and use the Greengrass IPC (Inter-Process Communication) client to subscribe to topics or receive messages. This approach allows your component to react to events in real-time.

2. Periodic execution: You can configure your component to run at specified intervals using a lifecycle configuration. This is useful for tasks that need to be performed regularly.

3. On-demand execution: Components can be triggered by other components or by cloud-initiated deployments.

To port a Lambda function to a native component, you'll need to:

1. Rewrite the Lambda handler as a long-running process or a script that can be executed periodically.
2. Implement the necessary IPC client code to subscribe to topics or receive messages that would have triggered the Lambda function.
3. Adjust the component's lifecycle configuration to determine how and when it should run.

The workload for this transition can vary depending on the complexity of your Lambda function and how it interacts with other parts of your Greengrass application. Simple Lambda functions might be relatively straightforward to port, while more complex ones could require significant refactoring.

As for signaling, instead of being invoked with an event, your native component would typically use the Greengrass IPC to subscribe to topics or receive messages. This allows it to react to the same types of events that would have invoked the Lambda function.

While this transition does require some code changes and a shift in how you think about your application's architecture, it can lead to more efficient and flexible implementations in Greengrass V2. The continuous running nature of native components can be particularly beneficial for scenarios where quick response times are crucial or where maintaining state between invocations is important.

Remember to thoroughly test your ported components to ensure they behave as expected in the Greengrass V2 environment.
Sources
Is there a presence event associated with my Greengrass v2 lambda component? | AWS re:Post
LambdaFunctionRecipeSource - AWS IoT Greengrass
Troubleshooting AWS IoT Greengrass V2 - AWS IoT Greengrass

Your understanding is correct, a native component will be able to run a script that you provide in its recipe which may either be a one-off script or a long running script. For your use case where you need some logic to execute after an event, a long running process in the run lifecycle step that can react to these events would likely be the right thing as you mentioned.

Depending on your specific use case, your component could either implement this logic itself or respond to messages over IPC (https://docs.aws.amazon.com/greengrass/v2/developerguide/interprocess-communication.html) which can allow multiple components to communicate with each other. IPC pubsub may be useful if you have a component that detects events to handle, publishes a message to a topic, and any other components subscribed to that topic may read the messages on that topic and call some logic based on the message.