From 2a234445f1c669b39a10a1d04178c0bea0f2dd24 Mon Sep 17 00:00:00 2001
From: Omprakash Mishra <omprakashmishra3978@example.com>
Date: Sun, 23 Jun 2024 00:24:55 +0000
Subject: [PATCH] Adding or updating the confluence pages

---
 .../Coding Patterns & Practices/Coding Patterns & Practices.md  | 2 +-
 patterns/docs/Coding Patterns & Practices/data.json             | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/patterns/docs/Coding Patterns & Practices/Coding Patterns & Practices.md b/patterns/docs/Coding Patterns & Practices/Coding Patterns & Practices.md
index f61e54e..a294333 100644
--- a/patterns/docs/Coding Patterns & Practices/Coding Patterns & Practices.md	
+++ b/patterns/docs/Coding Patterns & Practices/Coding Patterns & Practices.md	
@@ -91,7 +91,7 @@ GitHub PRs - Commits
 PR Review and Practices
 =======================
 
-*   PR titles should follow conventional commit.
+*   PR titles should follow conventional commit (eg. [https://www.conventionalcommits.org/en/v1.0.0/](https://www.conventionalcommits.org/en/v1.0.0/)).
 *   Branches should also follow a similar pattern (eg. feat/$featurename)
 *   A single PR should be for a single Feature/bug/hotfix/patch/etc and kept as small as possible and reasonable
 *   Add appropriate labels established by your team. (eg. Adding labels to also indicate the applications being impacted by the PR, for instance, "web" or "API")
diff --git a/patterns/docs/Coding Patterns & Practices/data.json b/patterns/docs/Coding Patterns & Practices/data.json
index a752136..c922e6d 100644
--- a/patterns/docs/Coding Patterns & Practices/data.json	
+++ b/patterns/docs/Coding Patterns & Practices/data.json	
@@ -1 +1 @@
-{"id":"160074735","type":"page","status":"current","title":"Coding Patterns & Practices","body":{"storage":{"value":"<ac:structured-macro ac:name=\"details\" ac:schema-version=\"1\" ac:macro-id=\"5f5c56f3-5d6c-46cf-ad8f-f3ff3d2ece6b\"><ac:parameter ac:name=\"label\" /><ac:rich-text-body><table class=\"wrapped relative-table\" style=\"width: 66.4076%;\"><colgroup><col style=\"width: 16.6678%;\" /><col style=\"width: 83.2901%;\" /></colgroup><tbody><tr><th>Status</th><td><div class=\"content-wrapper\"><p><ac:structured-macro ac:name=\"status\" ac:schema-version=\"1\" ac:macro-id=\"a2e29e0a-14d5-42cd-922b-bfb7364904e6\"><ac:parameter ac:name=\"colour\">Green</ac:parameter><ac:parameter ac:name=\"title\">Published</ac:parameter></ac:structured-macro> </p></div></td></tr><tr><th>Overview</th><td><div class=\"content-wrapper\"><p>The purpose of this page is to outline some coding practices when developing an application. Practices used by a team should be documented in the repository.</p></div></td></tr></tbody></table></ac:rich-text-body></ac:structured-macro><p><ac:structured-macro ac:name=\"toc\" ac:schema-version=\"1\" ac:macro-id=\"84e0863f-4cf8-4754-bef9-f9efdc7e9dd5\" /></p><h1>Languages Supported</h1><p>Currently, most agile teams use one of these 4 languages and it is encouraged to stay within these languages, it may expand in the future. ( Typescript/JavaScript, Java On Native, Python, <ac:inline-comment-marker ac:ref=\"caa2b41e-e793-4e43-81aa-ffda13c07472\">Go</ac:inline-comment-marker>)</p><h1>Native Deployments</h1><p>Some Languages are interpreted by their runtime ex:(java on JVM, python, javascript, etc..) whereas some languages are compiled (Golang, Rust).</p><p>Use native(static binary) deployments wherever available. for ex: it is a <strong>MUST </strong>for teams using Java to deploy using GraalVM native image without the overhead of JVM interpreter. </p><p>Focus on the scale-out vs scale-up as deployments are into containers or serverless.</p><h1>Code Design Patterns and Principles</h1><ul><li>Apply SOLID and DRY principles. (<a href=\"https://www.freecodecamp.org/news/solid-principles-explained-in-plain-english/\">https://www.freecodecamp.org/news/solid-principles-explained-in-plain-english</a>, <a href=\"https://www.baeldung.com/cs/dry-software-design-principle\">https://www.baeldung.com/cs/dry-software-design-principle</a>)</li><li>Use Composition over inheritance as much as possible.</li><li>Use IOC(Inversion of Control) pattern for dependency Injection, following constructor-based injection over setter or field-based injection.</li><li>The Service Layer should contain all the business logic of the application, and wrap each atomic transaction in the proper transaction boundary, Use transactions for read-only methods as well for ex: GET endpoints.<ul><li>(controller/endpoints → service → repository/active record → entity/query/mutation)</li><li>The controller should call the service or multiple services inside a transaction boundary to perf</li><li>orm the atomic operation.</li><li>The Service Layer MUST have a transactional context.</li></ul></li><li>Use Lazy Loading and Cascading in ORM to avoid fetching child entities unnecessarily and also make sure the mutations are cascaded as well.</li><li>Follow the TDD approach and the unit tests become living documentation of code, Stub external services with some sort of code, ex in java :- wiremock or powermock, split test lifecycles, so that UTs and Integration Tests can run independently.</li><li>Follow The Twelve-Factor App standards -<span> </span><a class=\"external-link\" href=\"https://12factor.net/\" rel=\"nofollow\">https://12factor.net/</a></li><li>Use testcontainers(<a href=\"https://www.testcontainers.org/\">https://www.testcontainers.org/</a>) or GHA services(<a href=\"https://docs.github.com/en/actions/using-containerized-services/about-service-containers\">https://docs.github.com/en/actions/using-containerized-services/about-service-containers</a>) for integration TESTS which includes, databases, queues, cache etc...</li></ul><h1>Folder Structure and Naming Conventions</h1><ul><li>Establish and understand your folder structure, if using a template avoid reorganizing (eg. <a href=\"https://github.com/bcgov/quickstart-openshift\">https://github.com/bcgov/quickstart-openshift</a>)</li><li>Have a common consistent way when creating names. (eg. for your controllers - The naming of controller APIs should be in line with the pattern of tag definition in swagger - Swagger Tag resource-subresource - URN resource/subresource/pathParameter/subresource)</li></ul><h1>Secret and Environment Variable Handling</h1><ul><li>Exercise the practice of least privilege (eg. Who can and should be able to access secrets) </li><li>Do not put sensitive information in the code, use a secret</li><li>Use environment variables when they may not be sensitive but change between environments (eg. Dev, Test, Prod)</li><li>Do not create secrets manually in Openshift.</li></ul><h1>Secure APIs</h1><ul><li>APIs should always be secured. This is generally achieved by using role based access based off their role validated via JWT.</li><li>The exception to this would be public APIs.</li></ul><h1>Error Handling</h1><ul><li>Gracefully handle errors</li><li>Use plain language when reporting an error. (example. If an error requires a user to do an action they should be able to follow the direction from the error)</li><li>Avoid generic language (eg. Error, review logs)</li></ul><p><br /></p><h1>Code Formatters and Plugins</h1><ul><li>Use common plugins and common formatters across team members to avoid flagging code as changed when it was just the format that was changed. (eg. Prettier, SQL Formatter, ESLint)</li><li>Share the IDE specific formatter in the GitHub to avoid conflicts</li></ul><h1>Infrastructure as Code</h1><ul><li>Keep in mind what happens when things go wrong, and how we recover. Maintain your infrastructure as code where possible. If it's not possible ensure you have sufficient documentation to stand back up your infrastructure.</li></ul><h1>Pipeline</h1><p>Align your CI/CD pipeline with your hosting environment (GitHub Actions for Openshift Silver/Gold, GitHub Actions with ArgoCD for Openshift Emerald, GiHub Actions with Terraform for AWS)</p><ul><li>Understand your DevOps pipeline (eg. What happens when I create a PR, merge a PR, how an image gets built, how code get tested)</li><li>Maintain your pipeline and align if possible to common practice (eg. <a href=\"https://github.com/bcgov/quickstart-openshift\">https://github.com/bcgov/quickstart-openshift</a>)</li></ul><p><span style=\"letter-spacing: 0.0px;\">The below was created using the </span><a class=\"external-link\" href=\"https://github.com/bcgov/quickstart-openshift\" rel=\"nofollow\">QuickStart OpenShift</a><span style=\"letter-spacing: 0.0px;\"> as a reference. Please refer to the repo for the most up to date information.</span></p><p><span style=\"letter-spacing: 0.0px;\"><ac:structured-macro ac:name=\"drawio\" ac:schema-version=\"1\" ac:macro-id=\"d42cd46c-ee4c-46bb-a91b-c9155cf840b8\"><ac:parameter ac:name=\"border\">true</ac:parameter><ac:parameter ac:name=\"diagramName\">Branching Strategy</ac:parameter><ac:parameter ac:name=\"simpleViewer\">false</ac:parameter><ac:parameter ac:name=\"width\" /><ac:parameter ac:name=\"links\">auto</ac:parameter><ac:parameter ac:name=\"tbstyle\">top</ac:parameter><ac:parameter ac:name=\"lbox\">true</ac:parameter><ac:parameter ac:name=\"diagramWidth\">1011</ac:parameter><ac:parameter ac:name=\"revision\">1</ac:parameter><ac:parameter ac:name=\"\" /></ac:structured-macro></span></p><h1 style=\"text-align: left;\">GitHub PRs - Commits</h1><ul style=\"text-align: left;\"><li>Follow the Conventional Commits for a better understanding -<span> </span><a class=\"external-link\" href=\"https://www.conventionalcommits.org/en/v1.0.0/\" rel=\"nofollow\">https://www.conventionalcommits.org/en/v1.0.0/</a></li></ul><h1>PR Review and Practices</h1><ul><li>PR titles should follow conventional commit.</li><li>Branches should also follow a similar pattern (eg. feat/$featurename)</li><li>A single PR should be for a single Feature/bug/hotfix/patch/etc and kept as small as possible and reasonable</li><li>Add appropriate labels established by your team. (eg. Adding labels to also indicate the applications being impacted by the PR, for instance, &quot;web&quot; or &quot;API&quot;)</li><li>Connect the issue using the button &quot;Connect Issue&quot;, if not available install the Chrome Extension<span> </span><a href=\"https://chrome.google.com/webstore/detail/zenhub-for-github/ogcgkffhplmphkaahpmffcafajaocjbd\" style=\"text-decoration: none;\" rel=\"nofollow\">ZenHub for GitHub</a><span> </span>or similar (this will help trace a completed task to the code modified)</li><li>If you are the author of the PR avoid resolving the comments, instead reply to them to let the reviewer be aware of your thoughts.</li><li>If you are a reviewer try to mark the comments as resolved to help the PR author to identify easily what is still missing.</li><li>Comments and conversations on the PR are good to let everyone be aware of what is happening but a quick call can also save a lot of time.</li><li>Once a review is raised, a reviewer should do the best effort to try to find a good moment to start. (eg. in the next 3 business hours. It does not mean finishing it in the 3 hours, just try to start providing some feedback. If multiple PRs are open at the same time the delays will be completely acceptable)</li><li>Review according to best practices for the code and application. PRs are about code review (<strong>not people review</strong>)</li><li>Have a merging practice. (eg. Squash the commits before merging to keep the main timeline clean)</li><li>Clean up your branches (eg. Delete the branch after the merge is done (after merging<span> </span>do not reuse the branch))</li></ul><h1>Dependency Management</h1><ul><li>It is <u><strong>strongly recommended to keep dependencies updated</strong></u> with automated pull requests from tools like <u><strong>Renovate, Snyk or Dependabot</strong></u>.</li><li>This introduces new features, fix bugs, address vulnerabilities or improve performance, affecting the quality, security, and functionality of a project.</li><li>Regular dependency pull requests help to keep changes small, up to date and, of course, manageable.</li><li>These pull requests should not be closed without careful consideration.  Unmerged updates should be written into an issue with reasoning and details to follow up in future.</li></ul><h1 class=\"with-breadcrumbs\">API framework evaluation factors</h1><p>The below outlines a few<span> </span><strong>key</strong><span> </span>considerations which would help in the decision-making of language/framework to use for API development for<span> </span><strong>containerized<span> </span></strong>environments.</p><p>Details around API Design are outlined here(<a class=\"external-link\" href=\"https://developer.gov.bc.ca/Data-and-APIs/BC-Government-API-Guidelines\" rel=\"nofollow\">https://developer.gov.bc.ca/Data-and-APIs/BC-Government-API-Guidelines</a>). The below points are on top of the guidelines provided in the link.</p><ol><li>Developer friendly, community support and libraries.</li><li>Resource Consumption(memory/CPU) the less the better, supports the move towards green computing.</li><li>Automated Open API 3 Specification generation, Swagger UI.</li><li>Automated DB schema management (flyway/Liquibase or something similar).</li><li>ORM integration for Database, ACID, Transaction support, Nested Transactions, Advanced Query with pagination, filter, sorting support.</li><li>Supports TDD(Test Driven Development) out of the box, which supports unit and integration testing.</li><li>Easiness of testing for pipelines and other automation.</li><li>Easiness of OAUTH2 integration.</li><li>Easiness of Circuit breaker integration and Resiliency.</li><li>API versioning.</li><li>Support for REST, GraphQL and gRPC</li><li>Asynchronous REST Client.</li><li>API Health checks(for liveness/readiness checks in Kubernetes world) out of the box which includes checking DB Connections and Message Broker connection (If present).</li><li>Easiness of writing to log files in different formats.</li><li>Switching Between Relational Database should be config only.</li><li>Easy Concurrency.</li><li>Easiness of Integration with Distributed tracing frameworks.</li></ol><p><br /></p><p><br /></p><p><br /></p>","representation":"storage","_expandable":{"content":"/rest/api/content/160074735"}},"_expandable":{"editor":"","view":"","export_view":"","styled_view":"","anonymous_export_view":""}},"extensions":{"position":9},"_links":{"webui":"/pages/viewpage.action?pageId=160074735","edit":"/pages/resumedraft.action?draftId=160074735","tinyui":"/x/74uKCQ","collection":"/rest/api/content","base":"https://apps.nrs.gov.bc.ca/int/confluence","context":"/int/confluence","self":"https://apps.nrs.gov.bc.ca/int/confluence/rest/api/content/160074735"},"_expandable":{"container":"/rest/api/space/AR","metadata":"","operations":"","children":"/rest/api/content/160074735/child","restrictions":"/rest/api/content/160074735/restriction/byOperation","history":"/rest/api/content/160074735/history","ancestors":"","version":"","descendants":"/rest/api/content/160074735/descendant","space":"/rest/api/space/AR"}}
\ No newline at end of file
+{"id":"160074735","type":"page","status":"current","title":"Coding Patterns & Practices","body":{"storage":{"value":"<ac:structured-macro ac:name=\"details\" ac:schema-version=\"1\" ac:macro-id=\"5f5c56f3-5d6c-46cf-ad8f-f3ff3d2ece6b\"><ac:parameter ac:name=\"label\" /><ac:rich-text-body><table class=\"wrapped relative-table\" style=\"width: 66.4076%;\"><colgroup><col style=\"width: 16.6678%;\" /><col style=\"width: 83.2901%;\" /></colgroup><tbody><tr><th>Status</th><td><div class=\"content-wrapper\"><p><ac:structured-macro ac:name=\"status\" ac:schema-version=\"1\" ac:macro-id=\"a2e29e0a-14d5-42cd-922b-bfb7364904e6\"><ac:parameter ac:name=\"colour\">Green</ac:parameter><ac:parameter ac:name=\"title\">Published</ac:parameter></ac:structured-macro> </p></div></td></tr><tr><th>Overview</th><td><div class=\"content-wrapper\"><p>The purpose of this page is to outline some coding practices when developing an application. Practices used by a team should be documented in the repository.</p></div></td></tr></tbody></table></ac:rich-text-body></ac:structured-macro><p><ac:structured-macro ac:name=\"toc\" ac:schema-version=\"1\" ac:macro-id=\"84e0863f-4cf8-4754-bef9-f9efdc7e9dd5\" /></p><h1>Languages Supported</h1><p>Currently, most agile teams use one of these 4 languages and it is encouraged to stay within these languages, it may expand in the future. ( Typescript/JavaScript, Java On Native, Python, <ac:inline-comment-marker ac:ref=\"caa2b41e-e793-4e43-81aa-ffda13c07472\">Go</ac:inline-comment-marker>)</p><h1>Native Deployments</h1><p>Some Languages are interpreted by their runtime ex:(java on JVM, python, javascript, etc..) whereas some languages are compiled (Golang, Rust).</p><p>Use native(static binary) deployments wherever available. for ex: it is a <strong>MUST </strong>for teams using Java to deploy using GraalVM native image without the overhead of JVM interpreter. </p><p>Focus on the scale-out vs scale-up as deployments are into containers or serverless.</p><h1>Code Design Patterns and Principles</h1><ul><li>Apply SOLID and DRY principles. (<a href=\"https://www.freecodecamp.org/news/solid-principles-explained-in-plain-english/\">https://www.freecodecamp.org/news/solid-principles-explained-in-plain-english</a>, <a href=\"https://www.baeldung.com/cs/dry-software-design-principle\">https://www.baeldung.com/cs/dry-software-design-principle</a>)</li><li>Use Composition over inheritance as much as possible.</li><li>Use IOC(Inversion of Control) pattern for dependency Injection, following constructor-based injection over setter or field-based injection.</li><li>The Service Layer should contain all the business logic of the application, and wrap each atomic transaction in the proper transaction boundary, Use transactions for read-only methods as well for ex: GET endpoints.<ul><li>(controller/endpoints → service → repository/active record → entity/query/mutation)</li><li>The controller should call the service or multiple services inside a transaction boundary to perf</li><li>orm the atomic operation.</li><li>The Service Layer MUST have a transactional context.</li></ul></li><li>Use Lazy Loading and Cascading in ORM to avoid fetching child entities unnecessarily and also make sure the mutations are cascaded as well.</li><li>Follow the TDD approach and the unit tests become living documentation of code, Stub external services with some sort of code, ex in java :- wiremock or powermock, split test lifecycles, so that UTs and Integration Tests can run independently.</li><li>Follow The Twelve-Factor App standards -<span> </span><a class=\"external-link\" href=\"https://12factor.net/\" rel=\"nofollow\">https://12factor.net/</a></li><li>Use testcontainers(<a href=\"https://www.testcontainers.org/\">https://www.testcontainers.org/</a>) or GHA services(<a href=\"https://docs.github.com/en/actions/using-containerized-services/about-service-containers\">https://docs.github.com/en/actions/using-containerized-services/about-service-containers</a>) for integration TESTS which includes, databases, queues, cache etc...</li></ul><h1>Folder Structure and Naming Conventions</h1><ul><li>Establish and understand your folder structure, if using a template avoid reorganizing (eg. <a href=\"https://github.com/bcgov/quickstart-openshift\">https://github.com/bcgov/quickstart-openshift</a>)</li><li>Have a common consistent way when creating names. (eg. for your controllers - The naming of controller APIs should be in line with the pattern of tag definition in swagger - Swagger Tag resource-subresource - URN resource/subresource/pathParameter/subresource)</li></ul><h1>Secret and Environment Variable Handling</h1><ul><li>Exercise the practice of least privilege (eg. Who can and should be able to access secrets) </li><li>Do not put sensitive information in the code, use a secret</li><li>Use environment variables when they may not be sensitive but change between environments (eg. Dev, Test, Prod)</li><li>Do not create secrets manually in Openshift.</li></ul><h1>Secure APIs</h1><ul><li>APIs should always be secured. This is generally achieved by using role based access based off their role validated via JWT.</li><li>The exception to this would be public APIs.</li></ul><h1>Error Handling</h1><ul><li>Gracefully handle errors</li><li>Use plain language when reporting an error. (example. If an error requires a user to do an action they should be able to follow the direction from the error)</li><li>Avoid generic language (eg. Error, review logs)</li></ul><p><br /></p><h1>Code Formatters and Plugins</h1><ul><li>Use common plugins and common formatters across team members to avoid flagging code as changed when it was just the format that was changed. (eg. Prettier, SQL Formatter, ESLint)</li><li>Share the IDE specific formatter in the GitHub to avoid conflicts</li></ul><h1>Infrastructure as Code</h1><ul><li>Keep in mind what happens when things go wrong, and how we recover. Maintain your infrastructure as code where possible. If it's not possible ensure you have sufficient documentation to stand back up your infrastructure.</li></ul><h1>Pipeline</h1><p>Align your CI/CD pipeline with your hosting environment (GitHub Actions for Openshift Silver/Gold, GitHub Actions with ArgoCD for Openshift Emerald, GiHub Actions with Terraform for AWS)</p><ul><li>Understand your DevOps pipeline (eg. What happens when I create a PR, merge a PR, how an image gets built, how code get tested)</li><li>Maintain your pipeline and align if possible to common practice (eg. <a href=\"https://github.com/bcgov/quickstart-openshift\">https://github.com/bcgov/quickstart-openshift</a>)</li></ul><p><span style=\"letter-spacing: 0.0px;\">The below was created using the </span><a class=\"external-link\" href=\"https://github.com/bcgov/quickstart-openshift\" rel=\"nofollow\">QuickStart OpenShift</a><span style=\"letter-spacing: 0.0px;\"> as a reference. Please refer to the repo for the most up to date information.</span></p><p><span style=\"letter-spacing: 0.0px;\"><ac:structured-macro ac:name=\"drawio\" ac:schema-version=\"1\" ac:macro-id=\"d42cd46c-ee4c-46bb-a91b-c9155cf840b8\"><ac:parameter ac:name=\"border\">true</ac:parameter><ac:parameter ac:name=\"diagramName\">Branching Strategy</ac:parameter><ac:parameter ac:name=\"simpleViewer\">false</ac:parameter><ac:parameter ac:name=\"width\" /><ac:parameter ac:name=\"links\">auto</ac:parameter><ac:parameter ac:name=\"tbstyle\">top</ac:parameter><ac:parameter ac:name=\"lbox\">true</ac:parameter><ac:parameter ac:name=\"diagramWidth\">1011</ac:parameter><ac:parameter ac:name=\"revision\">1</ac:parameter><ac:parameter ac:name=\"\" /></ac:structured-macro></span></p><h1 style=\"text-align: left;\">GitHub PRs - Commits</h1><ul style=\"text-align: left;\"><li>Follow the Conventional Commits for a better understanding -<span> </span><a class=\"external-link\" href=\"https://www.conventionalcommits.org/en/v1.0.0/\" rel=\"nofollow\">https://www.conventionalcommits.org/en/v1.0.0/</a></li></ul><h1>PR Review and Practices</h1><ul><li>PR titles should follow conventional commit (eg. <a class=\"\" href=\"https://www.conventionalcommits.org/en/v1.0.0/\">https://www.conventionalcommits.org/en/v1.0.0/</a>).</li><li>Branches should also follow a similar pattern (eg. feat/$featurename)</li><li>A single PR should be for a single Feature/bug/hotfix/patch/etc and kept as small as possible and reasonable</li><li>Add appropriate labels established by your team. (eg. Adding labels to also indicate the applications being impacted by the PR, for instance, &quot;web&quot; or &quot;API&quot;)</li><li>Connect the issue using the button &quot;Connect Issue&quot;, if not available install the Chrome Extension<span> </span><a href=\"https://chrome.google.com/webstore/detail/zenhub-for-github/ogcgkffhplmphkaahpmffcafajaocjbd\" style=\"text-decoration: none;\" rel=\"nofollow\">ZenHub for GitHub</a><span> </span>or similar (this will help trace a completed task to the code modified)</li><li>If you are the author of the PR avoid resolving the comments, instead reply to them to let the reviewer be aware of your thoughts.</li><li>If you are a reviewer try to mark the comments as resolved to help the PR author to identify easily what is still missing.</li><li>Comments and conversations on the PR are good to let everyone be aware of what is happening but a quick call can also save a lot of time.</li><li>Once a review is raised, a reviewer should do the best effort to try to find a good moment to start. (eg. in the next 3 business hours. It does not mean finishing it in the 3 hours, just try to start providing some feedback. If multiple PRs are open at the same time the delays will be completely acceptable)</li><li>Review according to best practices for the code and application. PRs are about code review (<strong>not people review</strong>)</li><li>Have a merging practice. (eg. Squash the commits before merging to keep the main timeline clean)</li><li>Clean up your branches (eg. Delete the branch after the merge is done (after merging<span> </span>do not reuse the branch))</li></ul><h1>Dependency Management</h1><ul><li>It is <u><strong>strongly recommended to keep dependencies updated</strong></u> with automated pull requests from tools like <u><strong>Renovate, Snyk or Dependabot</strong></u>.</li><li>This introduces new features, fix bugs, address vulnerabilities or improve performance, affecting the quality, security, and functionality of a project.</li><li>Regular dependency pull requests help to keep changes small, up to date and, of course, manageable.</li><li>These pull requests should not be closed without careful consideration.  Unmerged updates should be written into an issue with reasoning and details to follow up in future.</li></ul><h1 class=\"with-breadcrumbs\">API framework evaluation factors</h1><p>The below outlines a few<span> </span><strong>key</strong><span> </span>considerations which would help in the decision-making of language/framework to use for API development for<span> </span><strong>containerized<span> </span></strong>environments.</p><p>Details around API Design are outlined here(<a class=\"external-link\" href=\"https://developer.gov.bc.ca/Data-and-APIs/BC-Government-API-Guidelines\" rel=\"nofollow\">https://developer.gov.bc.ca/Data-and-APIs/BC-Government-API-Guidelines</a>). The below points are on top of the guidelines provided in the link.</p><ol><li>Developer friendly, community support and libraries.</li><li>Resource Consumption(memory/CPU) the less the better, supports the move towards green computing.</li><li>Automated Open API 3 Specification generation, Swagger UI.</li><li>Automated DB schema management (flyway/Liquibase or something similar).</li><li>ORM integration for Database, ACID, Transaction support, Nested Transactions, Advanced Query with pagination, filter, sorting support.</li><li>Supports TDD(Test Driven Development) out of the box, which supports unit and integration testing.</li><li>Easiness of testing for pipelines and other automation.</li><li>Easiness of OAUTH2 integration.</li><li>Easiness of Circuit breaker integration and Resiliency.</li><li>API versioning.</li><li>Support for REST, GraphQL and gRPC</li><li>Asynchronous REST Client.</li><li>API Health checks(for liveness/readiness checks in Kubernetes world) out of the box which includes checking DB Connections and Message Broker connection (If present).</li><li>Easiness of writing to log files in different formats.</li><li>Switching Between Relational Database should be config only.</li><li>Easy Concurrency.</li><li>Easiness of Integration with Distributed tracing frameworks.</li></ol><p><br /></p><p><br /></p><p><br /></p>","representation":"storage","_expandable":{"content":"/rest/api/content/160074735"}},"_expandable":{"editor":"","view":"","export_view":"","styled_view":"","anonymous_export_view":""}},"extensions":{"position":9},"_links":{"webui":"/pages/viewpage.action?pageId=160074735","edit":"/pages/resumedraft.action?draftId=160074735","tinyui":"/x/74uKCQ","collection":"/rest/api/content","base":"https://apps.nrs.gov.bc.ca/int/confluence","context":"/int/confluence","self":"https://apps.nrs.gov.bc.ca/int/confluence/rest/api/content/160074735"},"_expandable":{"container":"/rest/api/space/AR","metadata":"","operations":"","children":"/rest/api/content/160074735/child","restrictions":"/rest/api/content/160074735/restriction/byOperation","history":"/rest/api/content/160074735/history","ancestors":"","version":"","descendants":"/rest/api/content/160074735/descendant","space":"/rest/api/space/AR"}}
\ No newline at end of file