Formatting in answer

[anuj-ti]

Problem: Sometimes the llm do not return the answer in a formatted manner.

id: cd23fddae5ea5bf652cd74c65ff2d053

question: give me a list of reasons devflows usage of AWS lambda? answer: Reasons for DevFlows usage of AWS Lambda include: deploying as Typescript functions with proxy functionality built into a Lambda Layer (1), changing the abstraction to be compatible with Lambda (2), managing efficient connection pooling (3), querying RDS RDBMS (4), handling asynchronous calls (5), creating adapters and customizing OAuth implementation details (6), batching support for better performance (7), building scheduled Lambda functions triggered by EventBridge rules (8), prioritizing Lambda implementations for better performance (10), combining multiple actions into a single Lambda function (11), re-platforming from Knative to AWS services (13), processing large amounts of data (14), supporting non-blocking actions (15), aligning with industry trends (16), building a large standard library of listeners (17), reducing the noisy neighbor problem (18), and moving off of Knative for better performance (19).

In the combined step, the llm result is unformatted. The intermediate steps are also unformatted.

Intermediate Steps:

[
    "
    Rather than try and optimize sidecars, I would build DevFlows Actions so they can be deployed as Typescript functions in Lambda with the proxy functionality built into a Lambda Layer.",
    " The design of actions being http servers means that to run on Lambda, the abstraction will need to change and every action will need to be updated to be compatible. This is being changed as part of the move to Lambda. The CN rebuild of invocables to work on Lambda introduced the concept of “functions” which is in line with this rebuild assessment.",
    " 
    Use AWS Lambda global variables to manage efficient connection pooling 
    Easy to implement and can scale to 100+ concurrent lambda invocations 
    Better performance compared to ScaleArc 
    Requires the Lambda code to be written using Node.js.",
    " This spec uses a lambda function to query an RDS RDBMS based on the provided connection settings. It provides data to the flow in an event stream of 1 row per event. The system uses Lambda global variables and open-source libraries to support connection pooling.",
    " 
    "Asynchronous calls can be handled using https://support.devflows.devgraph.com/hc/en-us/articles/360021685559-Non-blocking-Actions#non-blocking actions in DevFlows. To the flow author, there is no difference; the asynchronous nature is handled internally. This is like using async / await in many programming languages."",
    " 
    To create an adapter in DevFlows we write Lambda functions which are lower level constructs compared to JSONata and friends. Integromat applications are created in the web IDE. The IDE provides a series of screens where a developer fills in JSON definitions. Each step is a request template that can be customised by an integration developer to account for particular OAuth implementation details. 

    Reasons for DevFlows usage of AWS Lambda:
    - To create an adapter
    - To fill in JSON definitions
    - To customise OAuth implementation details",
    " Option (2) will lead to one ElasticSearch update request for every document. This leads to poor performance and ElasticSearch recommends https://www.elastic.co/guide/en/elasticsearch/reference/master/tune-for-indexing-speed.html[[.underline]#avoiding#] single-document index requests. Instead, we use the batching support provided in this https://docs.google.com/document/d/1hRMaz_J4dUfWQ7L84IZthrn5xaUjdpiv8nPlgcoR4AU/edit#heading=h.u16xk7bmvdsz[[.underline]#spec#]. Batch support in DevFlows is provided by placing a SQS queue in front of every node proxy and sending the events to the Lambda function implementing the action only once the batch is ready. The ElasticSearch adapter can then process all these events and ingest the data into ElasticSearch in a single bulk write.",
    " 
    Build a scheduled Lambda function, triggered by EventBridge rules, to poll feed destinations.",
    " None.",
    " 
    "One consequence of this is that existing applications may have cold start times, for example creating Hibernate connections and fetching schema information at start up." 
    "I would prioritize Lambda implementations. I would make long running applications be separately deployed outside of the core of DevFlows, but allow communication with them by writing Lambda wrappers that can make the external HTTP requests."",
    " 
    The approach though the team is taking with the introduction of Lambda support is to make each proxy be a Lambda function, which then synchronously calls the action as a second lambda function. The proxy is triggered from SNS and once the action completes fires the next event to SNS. 
    I would change the programming model to be an API model in TypeScript, deploy in Lambda, and handle the DevFlows platform work in a Lambda layer. Using this model the DevFlows platform would be free to combine multiple Actions into a single Lambda function as an optimization.",
    " 
    - Bet fully on AWS - Lambda for serverless compute and SNS or EventBridge (needs a deeper dive with AWS) for eventing. This transformation is currently being executed by the DevFlows Code Nation team with a focus on Lambda and SNS, though the plan is to keep Kubernetes also.
    - Move the programming metaphor for Actions (invocables) to be functions rather than REST endpoints. This would make it easier to run the proxy logic in the same instance as the Action, would allow us to optimize and combine different functions into a single runtime activity and would standardize our Action development on a single language (Typescript). The Lambda change currently occurring will add a function paradigm, but will preserve the existing approach in parallel.",
    " 
    Re-platforming from Knative eventing to AWS SNS and from Knative serving to Lambda functions. We should schedule time with AWS to get deep on whether SNS or EventBridge make the most sense here. Reportedly the EventBridge team said we should use their service over SNS, but the SNS team may say the exact opposite. We do know that EventBridge’s origin was in the CloudWatch events space, so we need to research this carefully.",
    " 
    Creating an event in DevFlows per row of data entering the system. 
    For large batches, store in S3, and require both the flow and the adapter developers to know how to deal with that. 
    Approach #1 is perfect for processing data through DevFlows, as the flow can map and reason on the data. 
    However this approach will result in two Lambda invocations per node triggered in a flow, with corresponding SNS messages. 
    A 10 node flow invoked 1,000 times will have 20,000 Lambda invocations and 10,000 SNS notifications.",
    "
    The DevFlows platform supports the concept of “https://support.devflows.devgraph.com/hc/en-us/articles/360021685559-Non-blocking-Actions[[.underline]#non-blocking Actions#]”, which allows an action to deliver its results by using additional infrastructure such as Fargate tasks, EventBridge and/or SNS notifications, or webhooks from external systems.",
    " 
    Option 1 aligns DevFlows with that trend and we believe it will avail DevFlows of more potential source systems over time.",
    " 
    "Instead, just as we need to determine the minimal set of Actions that make up the DevFlows language, we need to determine the minimal set of Actions to make up Listeners. At least as a starting solution, the minimal set would appear to be a “Lambda Listener”. 

    While calling a Lambda function will not be a typical starting point, it _is_ the common denominator in all the listeners developed so far. For example, the existing HTTP listener is implemented using API Gateway and Lambda function. It is easy to imagine how we could quickly and easily build a large Standard Library of Listeners on top of this one primitive - HTTP, SQS, SNS, AppSync, EventBridge, Schedule, etc.",
    " DevFlows currently uses one single AWS account for all workspaces in a given installation. There are two installations - one owned by CNU and the other owned by Central Engineering. A single flow being capacity tested can exceed the AWS Lambda concurrency in a given AWS account (1,000 concurrent Lambdas default limit). When the limit is reached, for synchronous requests (e.g. API Gateway) there are no retries and 429 error codes are returned. For asynchronous requests (e.g. EventBridge or SNS) there are 2 further retries. Our throttling approach will reduce concurrent Lambda invocations through batching and reducing the number of proxies. Our AWS Accounts approach will allow each workspace to have its own AWS Account, reducing the noisy neighbor problem of one flow interrupting others.",
    " Moving off of Knative and onto Lambda would help here.",
    "
    At runtime, actions are invoked by DevFlows. The DevFlows proxy passes the event and configuration to the action Lambda function."
]