Add support for an HTTP/FaaS runtime

[fmvilas]

Reason/Context

We're currently hosting the functions within the same repository but it could be useful to have them as serverless functions.

Description

Implement an HTTP runtime that will make an HTTP call to a FaaS (Function as a Service) provider and waits for the HTTP response.

The HTTP response may vary from one provider to another. From the top of my head, we should support AWS Lambda, Netlify functions, Vercel, Azure Functions, GCP Cloud Functions.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴
It will be closed in 60 days if no further activity occurs. To unstale this issue, add a comment with detailed explanation.
Thank you for your contributions ❤️

[boyney123]

@fmvilas interesting idea for sure.

So here is a use case (is this what you mean)

1. User has asyncapi file (lets say basic WebSocket for now)
2. We know from the file we can listen for the event onMessage
3. Rather than doing onMessage locally, user wants to trigger external function (lambda, netlify etc).
4. When onMessage comes to our application, we trigger the function for the user (using HTTP + apis)
5. We read the response and give the user feedback (somehow).

Is this the kinda flow you mean?

[fmvilas]

Yeah! The last point is optional though. Depending on the protocol we may not be able to give any feedback to the user.

[sudoshreyansh]

@fmvilas The runtime mechanism was removed in #212, so is this feature still relevant?

[darp99]

Hello sir, @fmvilas
This sounds really interesting if no one is working on this issue then i like to work on this for a part of mentorship program but i have to first learn required skills for this so can i get help form you for move ahead.

[fmvilas]

Awesome! Yeah, no worries. During the mentorship program, I'll be here to support you. If this issue gets selected, of course 😄

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️

[fmvilas]

This is still relevant, @github-actions. Please don't close it 🙏

[KhudaDad414]

@fmvilas
There are a few points that I would need some input on:

1. Do users need to have the FaaS function already in place, or will they be able to write their function in Glee and have us generate the functions for them to upload to their FaaS provider?
2. What should the user interface for this feature look like? I understand that users need to provide the link to their endpoint and the method for calling it, but I'm not sure how they would do this in the interface. Can you provide more details on how this feature would work in practice?

@Souvikns anything from your side?

[KhudaDad414]

After considering different approaches to resolving this issue with the help of @fmvilas, three potential solutions were identified.

1) Utilizing Extensions in the AsyncAPI File

This solution appears to be an obvious first choice. By adding an extension such as x-glee-trigger to the messages or channels in the specification file, Glee can handle it automatically. However, one drawback of this approach is that it would require adding another configuration to specify the TOKEN or similar information in the Glee configuration.

2) Exporting Configuration from the Functions

The current approach that we use for lifecycle methods. Where a function and the corresponding triggering event are returned.
This approach is logical for functions as well. By returning a function and its configuration from the file in the functions folder, it is possible to specify what should be called, which method to use, and the header and body. This method appears to be a compelling option as it requires no additional configuration and can also address authentication concerns by allowing the user to parse their token and include it in the header. However, the downside of this approach is that it needs to be done for every operation, which can become complex when working with protocols that only have one channel, such as WebSockets.

3) Adding a trigger Option Alongside send or reply

In my opinion, the third option offers the greatest level of flexibility. It provides additional versatility that the second option does not have, by allowing for chaining of calls. While this may result in a coupling issue, it can also be considered a feature, as the user has the choice to utilize it or not. For example, if the return of a SaaS function is another function, Glee has the capability to call it as well. Additionally, it allows for the function to carry out its normal actions, such as sending or broadcasting results, while also triggering another SaaS function. Overall, I do not perceive any major drawbacks with this solution.

[Souvikns]

@KhudaDad414 Help me understand here, is this the flow you are going with

some data gets published to Glee --> control goes to Glee function --> Glee function returns another functions and some config --> glee uses that config to make API call and then calls the returned functions with the response

can't I make the API call in glee function itself as part of my business logic.

[KhudaDad414]

@Souvikns

some data gets published to Glee --> control goes to Glee function --> Glee function returns another functions and some config --> glee uses that config to make API call and then calls the returned functions with the response

more or less.
this is what I think the flow should be.
some data gets published to Glee --> control goes to Glee function --> Glee function has the option to send trigger alongside send and/or reply --> glee makes the API call and then evaluates the response.

what it should do with the response?

Short answer, I don't know. 😆
IMO we have two options here. We can send/reply the response or we can treat the response just like a Glee function response. this way a function can return another trigger/send/reply object. this enables us to chain the function calls but it creates a coupling issue.

can't I make the API call in glee function itself as part of my business logic.

You definitely can but glee can abstract the API call for you. like retrying the call in case it fails with the 429 error code. etc.

[fmvilas]

we can treat the response just like a Glee function response

We should definitely treat the response the same way we treat a function's return. The idea is to be able to decouple the function's code from Glee and JS/TS, so people can write their functions in any programming language.

this enables us to chain the function calls but it creates a coupling issue.

Well, this creates coupling but it doesn't have to necessarily be an issue. Some people would argue it is and some will not. IMHO, Glee shouldn't make any opinion on that matter since it's an architectural decision.

like retrying the call in case it fails with the 429 error code. etc.

This! 💯 Anyone can make an HTTP call but making sure you retry it if it fails, you adapt to rate limiting issues, etc. is what actually makes it production-ready.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️