{
"id": "1WjGNzBvE4iLVhSGR1X1TMq5U7e0mHe2dDCDquQOguS4_2",
"kg": {
"nodes": [
{
"id": "Insights",
"type": "concept",
"dbpedia": "https://dbpedia.org/resource/Insights",
"desc": "A section of the document that provides insights or guidelines."
},
{
"id": "Foundation Assessment",
"type": "concept",
"dbpedia": null,
"desc": "A subsection of the document that assesses the foundation of the product."
},
{
"id": "FIT TO BUILD ON?",
"type": "concept",
"dbpedia": null,
"desc": "A question regarding the fit of the product for making changes."
},
{
"id": "EXPLANATION",
"type": "concept",
"dbpedia": null,
"desc": "An explanation related to the fit of the product for making changes."
},
{
"id": "P2 Feedback",
"type": "concept",
"dbpedia": null,
"desc": "A section of the document that provides feedback on the P2 spec."
},
{
"id": "The request is understandable of using this P2 spec as a placeholder for\nnode-type capabilities that we will create iterations on. However, this\nspec already has complexity in handling error codes, and adding all\nnode-type level capabilities to a single spec will lead to a massive\nspec. We need some kind of hierarchy here where there is a higher level\nspec for all node type capabilities and responsibilities, and more\ndetailed specs for error handling, logging, accessing to DevFlows APIs,\n3rd party developer experience, etc. It is recommended that we do NOT\ntry to jam this all into a single spec.",
"type": "concept",
"dbpedia": null,
"desc": "Feedback regarding the complexity of the P2 spec and the need for a hierarchy."
},
{
"id": "In terms of error handling, our approach to tooling will differ based on\nwho our target customers are. If they are engineers in Central\nEngineering at DevFactory, then we can reasonably expect a level of\nsophistication and access to AWS tools, whereby AWS X-ray or Prometheus\nmay be useful options. But given our vision of DevFlows being for IT\nscripting developers, we are forced to think of solutions that are\neasier to use and avoid requiring additional AWS permissions.",
"type": "concept",
"dbpedia": null,
"desc": "Information regarding the approach to error handling based on the target customers."
},
{
"id": "See this document on\nhttps: or or docs.google.com or document or d or 1SpPG8kXx5BSTmxA_GHPbMZMoKUGXD2fhWQevZBKuF2I or edit#heading=h.q77p30yiqbq3[[.underline]#best\npractices for flow development#] (put together by the Cost Optimization\nteam in Central Engineering based on their experience using DevFlows).\nWe need to work to simplify life for flow developers, rather than force\nthem to worry about rate limits, throttling, retries and garbage\ncollection. This provide a good roadmap for other topics we should\ntackle specifically:\n\n[arabic]\n. {blank}\n+\n____\nIdempotency guidelines.\n____\n. {blank}\n+\n____\nRate limits and throttling in DevFlows.\n____\n. {blank}\n+\n____\nHow INPUT nodes should handle retries.\n____",
"type": "concept",
"dbpedia": null,
"desc": "A reference to a document providing best practices for flow development."
},
{
"id": "DevFlows currently has scaling limits due to Knative, but once the\nmigration to SNS and Lambda is completed, then scalability should be a\nfunction of our AWS accounts. At that point, any throttling to work\nwithin those constraints will be at the account level not the flow\nlevel. Similarly any limits on specific resources, for example\nSalesforce.coms notorious API limits, should be handled at the Adapter\nlevel rather than by flows.",
"type": "concept",
"dbpedia": null,
"desc": "Information regarding the scaling limits of DevFlows and the handling of specific resource limits."
},
{
"id": "Making hard problems simple for (flow) developers is a worthy hard\nproblem for the platform to solve.",
"type": "concept",
"dbpedia": null,
"desc": "A statement emphasizing the importance of making hard problems simple for flow developers."
},
{
"id": "Engineering Insights",
"type": "concept",
"dbpedia": "https://dbpedia.org/resource/Engineering_Insights",
"desc": "A section of the document that provides insights or guidelines for engineering."
},
{
"id": "Handling the rollout will have implications since many DevFlows\ninvocables currently mostly throw 500 errors, and that is currently\ntreated as a retry case by DevFlows. This spec moves retry logic to be\nspecific to timeout and temporary failure cases.",
"type": "concept",
"dbpedia": null,
"desc": "Insights regarding the implications of handling the rollout and the retry logic."
},
{
"id": "Scope Details",
"type": "concept",
"dbpedia": null,
"desc": "A section of the document that provides details about the scope."
},
{
"id": "Input Constraints",
"type": "concept",
"dbpedia": null,
"desc": "A subsection of the document that discusses the input constraints."
},
{
"id": "Create a spec that will cover all the interfaces for an extensible node\ntype into DevFlows, not just error handling, but make the first\niteration focused on error handling.",
"type": "concept",
"dbpedia": null,
"desc": "A constraint regarding the creation of a spec for an extensible node type."
}
],
"edges": [
{
"source": "Foundation Assessment",
"type": "FIT_TO_BUILD_ON",
"target": "FIT TO BUILD ON?"
},
{
"source": "Foundation Assessment",
"type": "EXPLANATION",
"target": "EXPLANATION"
},
{
"source": "P2 Feedback",
"type": "P2_FEEDBACK",
"target": "The request is understandable of using this P2 spec as a placeholder for\nnode-type capabilities that we will create iterations on. However, this\nspec already has complexity in handling error codes, and adding all\nnode-type level capabilities to a single spec will lead to a massive\nspec. We need some kind of hierarchy here where there is a higher level\nspec for all node type capabilities and responsibilities, and more\ndetailed specs for error handling, logging, accessing to DevFlows APIs,\n3rd party developer experience, etc. It is recommended that we do NOT\ntry to jam this all into a single spec."
},
{
"source": "P2 Feedback",
"type": "ERROR_HANDLING",
"target": "In terms of error handling, our approach to tooling will differ based on\nwho our target customers are. If they are engineers in Central\nEngineering at DevFactory, then we can reasonably expect a level of\nsophistication and access to AWS tools, whereby AWS X-ray or Prometheus\nmay be useful options. But given our vision of DevFlows being for IT\nscripting developers, we are forced to think of solutions that are\neasier to use and avoid requiring additional AWS permissions."
},
{
"source": "P2 Feedback",
"type": "BEST_PRACTICES",
"target": "See this document on\nhttps://docs.google.com/document/d/1SpPG8kXx5BSTmxA_GHPbMZMoKUGXD2fhWQevZBKuF2I/edit#heading=h.q77p30yiqbq3[[.underline]#\u201cbest\npractices for flow development\u201d#] (put together by the Cost Optimization\nteam in Central Engineering based on their experience using DevFlows).\nWe need to work to simplify life for flow developers, rather than force\nthem to worry about rate limits, throttling, retries and garbage\ncollection. This provide a good roadmap for other topics we should\ntackle specifically:\n\n[arabic]\n. {blank}\n+\n____\nIdempotency guidelines.\n____\n. {blank}\n+\n____\nRate limits and throttling in DevFlows.\n____\n. {blank}\n+\n____\nHow INPUT nodes should handle retries.\n____"
},
{
"source": "P2 Feedback",
"type": "SCALABILITY",
"target": "DevFlows currently has scaling limits due to Knative, but once the\nmigration to SNS and Lambda is completed, then scalability should be a\nfunction of our AWS accounts. At that point, any throttling to work\nwithin those constraints will be at the account level not the flow\nlevel. Similarly any limits on specific resources, for example\nSalesforce.com\u2019s notorious API limits, should be handled at the Adapter\nlevel rather than by flows."
},
{
"source": "P2 Feedback",
"type": "PROBLEM_SOLVING",
"target": "Making hard problems simple for (flow) developers is a worthy hard\nproblem for the platform to solve."
},
{
"source": "Engineering Insights",
"type": "INSIGHTS",
"target": "Handling the rollout will have implications since many DevFlows\ninvocables currently mostly throw 500 errors, and that is currently\ntreated as a retry case by DevFlows. This spec moves retry logic to be\nspecific to timeout and temporary failure cases."
},
{
"source": "Scope Details",
"type": "INPUT_CONSTRAINTS",
"target": "Create a spec that will cover all the interfaces for an extensible node\ntype into DevFlows, not just error handling, but make the first\niteration focused on error handling."
}
]
},
"metadata": {
"name": "ascii/1WjGNzBvE4iLVhSGR1X1TMq5U7e0mHe2dDCDquQOguS4.json",
"parents": "llm-kb-dataset",
"mimeType": "application/json",
"originalFileSource": "https://docs.google.com/document/d/1gQ_EqhlGn0gKSUGjvII-bqhejPykjDC35g-Muf4QIhI",
"originalOwnersName": "Steve Brain",
"originalModifiedTime": "2022-08-13T07:49:16.216Z",
"originalOwnersEmail": "steve.brain@devfactory.com",
"originalCreatedTime": "2021-03-24T11:31:56.603Z",
"kgNodeId": null
}
}
anuj-ti
commented
1 year ago