From 6d385862ef86a78649df5f3f648e90f5d5d7765a Mon Sep 17 00:00:00 2001 From: Ryan Koch <4325613+Ryan-Koch@users.noreply.github.com> Date: Tue, 7 Nov 2023 13:00:13 -0500 Subject: [PATCH 1/9] Starting a draft with some initial explanation. Will add in alternatives and ask others to do the same. --- ...06-web-development-framework-preference.md | 32 +++++++++++++++++++ 1 file changed, 32 insertions(+) create mode 100644 docs/appeng/adrs/0006-web-development-framework-preference.md diff --git a/docs/appeng/adrs/0006-web-development-framework-preference.md b/docs/appeng/adrs/0006-web-development-framework-preference.md new file mode 100644 index 00000000..ef1ead57 --- /dev/null +++ b/docs/appeng/adrs/0006-web-development-framework-preference.md @@ -0,0 +1,32 @@ +# 0006 - Preference for x as web development framework(s) + +**Status:** Draft + +**Date Accepted:** x/x/xxxx + +## Context + +Our partners look to us for our expertise and our opinions on a variety of topics, including the tools we use to build software together. As we continue to seek new business it is beneficial for us to have an organizational opinion on what web development framework to use (when we have a choice in the matter). + +In making a choice we're seeking to match up the tradeoffs that the tools provide with projected partnership needs. The technical ecosystems we operate in tend to change often, so this is a decision we should seek to re-evaluate at least annually. Some topics to consider in the decision include: +- Accessibility for junior engineers. +- Support for rapid prototyping. +- Ability to use in 'enterprise' environments. +- Batteries included vs. things we have to roll ourselves. + - e.g authentication and authorization tooling, data model management, caching, etc + +(this list is likely not complete, feel free to modify or add to it as we put this draft together) + +The decision outcome does not need to be a single framework. Ideally we'll choose 2-3 that we would ask folks to choose from in most scenarios. + +## Decision +Put a decision outcome here when ready. + +## Why is this applicable to the Practice as a whole? + +A large portion of our work is focused on developing web apps in partnership with public and private organizations. Each time something new starts we need to make decisions about how we'd like to approach it. This is meant to help give guidance in order to lower the burden of that choice. + +Having a 'practice opinion' on these tools will also help support folks' professional development, as well as our hiring and on-boarding processes. As we hire and get folks up to speed, this decision may be able to help us tailor what we do toward 'what we're trying to be good at.' Similarly we could lean on this as we seek to provide resources for folks developing their professional development plans. + +## Alternatives Considered + From 34dbaa627c2909bb29383dbcb4c8ae6821ca5fe9 Mon Sep 17 00:00:00 2001 From: Ryan Koch <4325613+Ryan-Koch@users.noreply.github.com> Date: Tue, 7 Nov 2023 14:17:35 -0500 Subject: [PATCH 2/9] Format fixes. --- .../adrs/0006-web-development-framework-preference.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/docs/appeng/adrs/0006-web-development-framework-preference.md b/docs/appeng/adrs/0006-web-development-framework-preference.md index ef1ead57..9819cee9 100644 --- a/docs/appeng/adrs/0006-web-development-framework-preference.md +++ b/docs/appeng/adrs/0006-web-development-framework-preference.md @@ -6,9 +6,10 @@ ## Context -Our partners look to us for our expertise and our opinions on a variety of topics, including the tools we use to build software together. As we continue to seek new business it is beneficial for us to have an organizational opinion on what web development framework to use (when we have a choice in the matter). +Our partners look to us for our expertise and our opinions on a variety of topics, including the tools we use to build software together. As we continue to seek new business it is beneficial for us to have an organizational opinion on what web development framework to use (when we have a choice in the matter). + +In making a choice we're seeking to match up the tradeoffs that the tools provide with projected partnership needs. The technical ecosystems we operate in tend to change often, so this is a decision we should seek to re-evaluate at least annually. Some topics to consider in the decision include: -In making a choice we're seeking to match up the tradeoffs that the tools provide with projected partnership needs. The technical ecosystems we operate in tend to change often, so this is a decision we should seek to re-evaluate at least annually. Some topics to consider in the decision include: - Accessibility for junior engineers. - Support for rapid prototyping. - Ability to use in 'enterprise' environments. @@ -20,13 +21,13 @@ In making a choice we're seeking to match up the tradeoffs that the tools provid The decision outcome does not need to be a single framework. Ideally we'll choose 2-3 that we would ask folks to choose from in most scenarios. ## Decision -Put a decision outcome here when ready. + +Put a decision outcome here when ready. ## Why is this applicable to the Practice as a whole? -A large portion of our work is focused on developing web apps in partnership with public and private organizations. Each time something new starts we need to make decisions about how we'd like to approach it. This is meant to help give guidance in order to lower the burden of that choice. +A large portion of our work is focused on developing web apps in partnership with public and private organizations. Each time something new starts we need to make decisions about how we'd like to approach it. This is meant to help give guidance in order to lower the burden of that choice. Having a 'practice opinion' on these tools will also help support folks' professional development, as well as our hiring and on-boarding processes. As we hire and get folks up to speed, this decision may be able to help us tailor what we do toward 'what we're trying to be good at.' Similarly we could lean on this as we seek to provide resources for folks developing their professional development plans. ## Alternatives Considered - From f7e7e66e312a7bf726311ee5466e9367c97c06fe Mon Sep 17 00:00:00 2001 From: Ryan Koch <4325613+Ryan-Koch@users.noreply.github.com> Date: Thu, 9 Nov 2023 11:34:01 -0500 Subject: [PATCH 3/9] Adds Django, Spring, and Express options with some pros and cons to get those sections started. --- ...06-web-development-framework-preference.md | 59 +++++++++++++++++++ 1 file changed, 59 insertions(+) diff --git a/docs/appeng/adrs/0006-web-development-framework-preference.md b/docs/appeng/adrs/0006-web-development-framework-preference.md index 9819cee9..1e5a978b 100644 --- a/docs/appeng/adrs/0006-web-development-framework-preference.md +++ b/docs/appeng/adrs/0006-web-development-framework-preference.md @@ -31,3 +31,62 @@ A large portion of our work is focused on developing web apps in partnership wit Having a 'practice opinion' on these tools will also help support folks' professional development, as well as our hiring and on-boarding processes. As we hire and get folks up to speed, this decision may be able to help us tailor what we do toward 'what we're trying to be good at.' Similarly we could lean on this as we seek to provide resources for folks developing their professional development plans. ## Alternatives Considered + +### Django + +#### Pros + +- `+` Mature framework that's been around since 2005. +- `+` Opinionated tooling for managing data migrations, potentially making the task more accessible for junior practitioners. +- `+` Strong ORM allowing the abstraction of many database interactions. +- `+` Features designed to make form creation and management easier. +- `+` Strong templating tooling +- `+` Possible to gain a portion of the features typically associated with single page applications, with less overhead by pairing the framework with something like [htmx](https://htmx.org/). +- `+` Uses the python programming language which enjoys broad community support, and is useful across multiple subpractices like web development and data science. +- `+` Provides batteries included tooling for authentication and authorization, caching, and an administrative console, among others. +- `+` Uses Python, which is considered easy to learn and is now frequently taught in both college and bootcamp programs. + +#### Cons + +- `-` Uses Python, which means learning a new programming language for those who haven't been exposed to it yet. +- `-` Different languages between backend and frontend if Javascript is needed for client interactions. +- `-` May need to use additional tooling for asynchronous workload use cases (message queues and workers). +- `-` Python's dynamic typing may lead to more effort spent on unit tests. But this can be mitigated some through [type hinting](https://docs.python.org/3/library/typing.html) + +### Spring + +#### Pros + +- `+` Mature framework that's been around since 2002. +- `+` Reactive programming model could be useful for a variety of use cases. +- `+` Spring boot is good for microservices where use cases call for that. +- `+` Batteries included tooling for things like authentication and authorization and caching, among others. +- `+` Java tooling is popular in enterprise spaces +- `+` Uses Java, which is commonly taught in college programs. +- `+` Java is statically typed which can give safety that would otherwise be gained through additional unit tests. + +#### Cons + +- `-` Big complex framework with a lot of capabilities, but may be less suited for rapid prototyping use cases. +- `-` Different languages between backend and frontend if Javascript is needed for client interactions. +- `-` Potentially too many features, need solid understanding of the framework to know what's most useful. Effort needed to keep team(s) in alignment on practices. +- `-` Potentially verbose configuration +- `-` Might have a steep learning curve for some, making it potentially more difficult to onboard junior practitioners. + +### Express.js + +#### Pros + +- `+` Strong performance for event driven workloads +- `+` Strong community support +- `+` Uses Javascript, which is commonly taught in bootcamp programs +- `+` Flexibility in how applications are structured (not opinionated). +- `+` Mature framework that's been around since 2010. +- `+` Can use typescript with this framework, allowing us to keep with [ADR 0001](https://playbook.truss.dev/docs/appeng/adrs/use-typescript) + +#### Cons + +- `-` Not opinionated, this lack of structure can make it more difficult to keep team(s) on the same page around specific practices and approaches. +- `-` Middleware(s) can grow to become unwiedly +- `-` Minimialist framework, so lacking in some batteries included features, leaving projects to choose other tools to add on with it. +- `-` If we're abdiding by prior ADRs it would mean using Typescript, which may have some learning curve for folks coming in without that background. From aa7e9e5f89779b4ba16382f9d5990e4c6b3c17ce Mon Sep 17 00:00:00 2001 From: Ryan Koch <4325613+Ryan-Koch@users.noreply.github.com> Date: Tue, 21 Nov 2023 11:41:54 -0500 Subject: [PATCH 4/9] Incorporate some feedback on additional pros and cons. --- .../0006-web-development-framework-preference.md | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/docs/appeng/adrs/0006-web-development-framework-preference.md b/docs/appeng/adrs/0006-web-development-framework-preference.md index 1e5a978b..84b4ade2 100644 --- a/docs/appeng/adrs/0006-web-development-framework-preference.md +++ b/docs/appeng/adrs/0006-web-development-framework-preference.md @@ -43,15 +43,20 @@ Having a 'practice opinion' on these tools will also help support folks' profess - `+` Strong templating tooling - `+` Possible to gain a portion of the features typically associated with single page applications, with less overhead by pairing the framework with something like [htmx](https://htmx.org/). - `+` Uses the python programming language which enjoys broad community support, and is useful across multiple subpractices like web development and data science. -- `+` Provides batteries included tooling for authentication and authorization, caching, and an administrative console, among others. +- `+` Provides batteries included tooling for authentication and authorization, caching, and an administrative console, among others. These make it easy to create a secure REST API quickly, making it a great option for rapid prototyping. - `+` Uses Python, which is considered easy to learn and is now frequently taught in both college and bootcamp programs. +- `+` Strong community support +- `+` Built-in Admin interface is useful for having a UI to interact with project database #### Cons -- `-` Uses Python, which means learning a new programming language for those who haven't been exposed to it yet. - `-` Different languages between backend and frontend if Javascript is needed for client interactions. - `-` May need to use additional tooling for asynchronous workload use cases (message queues and workers). - `-` Python's dynamic typing may lead to more effort spent on unit tests. But this can be mitigated some through [type hinting](https://docs.python.org/3/library/typing.html) +- `-` Since Django is highly opinionated, if you're new to it it'll seem like there's a lot of "magic" under the hood. Compared to smaller frameworks like Flask the learning curve is can be steep. +- `-` Django is a REST framework, so it doesn't have great websocket support. +- `-` Limitations around async support, with potential performance implications. More on this in the [Django async documentation](https://docs.djangoproject.com/en/4.2/topics/async/). +- `-` Opinionated toward monolithic apps, may not be a good choice for microservices use cases. ### Spring @@ -82,11 +87,10 @@ Having a 'practice opinion' on these tools will also help support folks' profess - `+` Uses Javascript, which is commonly taught in bootcamp programs - `+` Flexibility in how applications are structured (not opinionated). - `+` Mature framework that's been around since 2010. -- `+` Can use typescript with this framework, allowing us to keep with [ADR 0001](https://playbook.truss.dev/docs/appeng/adrs/use-typescript) +- `+` Can use typescript with this framework, allowing us to keep with [ADR 0001](https://playbook.truss.dev/docs/appeng/adrs/use-typescript). #### Cons - `-` Not opinionated, this lack of structure can make it more difficult to keep team(s) on the same page around specific practices and approaches. -- `-` Middleware(s) can grow to become unwiedly - `-` Minimialist framework, so lacking in some batteries included features, leaving projects to choose other tools to add on with it. - `-` If we're abdiding by prior ADRs it would mean using Typescript, which may have some learning curve for folks coming in without that background. From f5061f8005e6c1d2a07b31938fdd787c192998c4 Mon Sep 17 00:00:00 2001 From: Ryan Koch <4325613+Ryan-Koch@users.noreply.github.com> Date: Tue, 28 Nov 2023 11:12:07 -0500 Subject: [PATCH 5/9] Add react and vue options. --- ...06-web-development-framework-preference.md | 34 +++++++++++++++++++ 1 file changed, 34 insertions(+) diff --git a/docs/appeng/adrs/0006-web-development-framework-preference.md b/docs/appeng/adrs/0006-web-development-framework-preference.md index 84b4ade2..eee78ea1 100644 --- a/docs/appeng/adrs/0006-web-development-framework-preference.md +++ b/docs/appeng/adrs/0006-web-development-framework-preference.md @@ -94,3 +94,37 @@ Having a 'practice opinion' on these tools will also help support folks' profess - `-` Not opinionated, this lack of structure can make it more difficult to keep team(s) on the same page around specific practices and approaches. - `-` Minimialist framework, so lacking in some batteries included features, leaving projects to choose other tools to add on with it. - `-` If we're abdiding by prior ADRs it would mean using Typescript, which may have some learning curve for folks coming in without that background. + +### Vue.js with Node.js + +#### Pros + +- `+` One programming language for both frontend and backend. +- `+` Node.js can be strong on concurrent request handling. +- `+` Considerable library/tooling support +- `+` Modular architecture can be useful for microservices +- `+` Strong community support + +#### Cons + +- `-` Projects have to figure out security implementation, which could introduce additional risk. +- `-` Server side rendering is possible but may be complex to set up and use +- `-` The flexibility this combination allows for may also allow for complexity creep. +- `-` Dependency management and keeping both parts of the stack in sync may introduct additional overhead. + +### React with Node.js + +#### Pros + +- `+` One programming language for both frontend and backend. +- `+` Node.js can be strong on concurrent request handling. +- `+` Considerable library/tooling support +- `+` Strong community support + +#### Cons + +- `-` Projects have to figure out security implementation, which could introduce additional risk. +- `-` React can have a steep learning curve when coming from other frameworks. +- `-` Server side rendering is possible but may be complex to set up and use +- `-` The flexibility this combination allows for may also allow for complexity creep. +- `-` Dependency management and keeping both parts of the stack in sync may introduct additional overhead. From 9cc7bd2e1f2a4501a7add5714bee0140ddb5c458 Mon Sep 17 00:00:00 2001 From: Ryan Koch <4325613+Ryan-Koch@users.noreply.github.com> Date: Wed, 6 Dec 2023 17:08:51 -0500 Subject: [PATCH 6/9] Update docs/appeng/adrs/0006-web-development-framework-preference.md Co-authored-by: Melissa Thai <141852867+melissathai@users.noreply.github.com> --- docs/appeng/adrs/0006-web-development-framework-preference.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/appeng/adrs/0006-web-development-framework-preference.md b/docs/appeng/adrs/0006-web-development-framework-preference.md index eee78ea1..9c7af465 100644 --- a/docs/appeng/adrs/0006-web-development-framework-preference.md +++ b/docs/appeng/adrs/0006-web-development-framework-preference.md @@ -53,7 +53,7 @@ Having a 'practice opinion' on these tools will also help support folks' profess - `-` Different languages between backend and frontend if Javascript is needed for client interactions. - `-` May need to use additional tooling for asynchronous workload use cases (message queues and workers). - `-` Python's dynamic typing may lead to more effort spent on unit tests. But this can be mitigated some through [type hinting](https://docs.python.org/3/library/typing.html) -- `-` Since Django is highly opinionated, if you're new to it it'll seem like there's a lot of "magic" under the hood. Compared to smaller frameworks like Flask the learning curve is can be steep. +- `-` Since Django is highly opinionated, if you're new to it it'll seem like there's a lot of "magic" under the hood. Compared to smaller frameworks like Flask the learning curve can be steep. - `-` Django is a REST framework, so it doesn't have great websocket support. - `-` Limitations around async support, with potential performance implications. More on this in the [Django async documentation](https://docs.djangoproject.com/en/4.2/topics/async/). - `-` Opinionated toward monolithic apps, may not be a good choice for microservices use cases. From c6da90c6ae70760863e5be63b6df58abce9a64cf Mon Sep 17 00:00:00 2001 From: Ryan Koch <4325613+Ryan-Koch@users.noreply.github.com> Date: Wed, 6 Dec 2023 17:09:00 -0500 Subject: [PATCH 7/9] Update docs/appeng/adrs/0006-web-development-framework-preference.md Co-authored-by: Melissa Thai <141852867+melissathai@users.noreply.github.com> --- docs/appeng/adrs/0006-web-development-framework-preference.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/appeng/adrs/0006-web-development-framework-preference.md b/docs/appeng/adrs/0006-web-development-framework-preference.md index 9c7af465..c033e5b4 100644 --- a/docs/appeng/adrs/0006-web-development-framework-preference.md +++ b/docs/appeng/adrs/0006-web-development-framework-preference.md @@ -93,7 +93,7 @@ Having a 'practice opinion' on these tools will also help support folks' profess - `-` Not opinionated, this lack of structure can make it more difficult to keep team(s) on the same page around specific practices and approaches. - `-` Minimialist framework, so lacking in some batteries included features, leaving projects to choose other tools to add on with it. -- `-` If we're abdiding by prior ADRs it would mean using Typescript, which may have some learning curve for folks coming in without that background. +- `-` If we're abiding by prior ADRs it would mean using Typescript, which may have some learning curve for folks coming in without that background. ### Vue.js with Node.js From 96fcda4c820b24f575969c145cf96c2efa1f6368 Mon Sep 17 00:00:00 2001 From: Melissa Thai Date: Wed, 17 Jan 2024 15:49:22 -0800 Subject: [PATCH 8/9] Summarize existing frontend and backend pros/cons, and add section on infrastructure --- ...06-web-development-framework-preference.md | 125 ++++++------------ 1 file changed, 41 insertions(+), 84 deletions(-) diff --git a/docs/appeng/adrs/0006-web-development-framework-preference.md b/docs/appeng/adrs/0006-web-development-framework-preference.md index c033e5b4..ae7a708f 100644 --- a/docs/appeng/adrs/0006-web-development-framework-preference.md +++ b/docs/appeng/adrs/0006-web-development-framework-preference.md @@ -8,7 +8,7 @@ Our partners look to us for our expertise and our opinions on a variety of topics, including the tools we use to build software together. As we continue to seek new business it is beneficial for us to have an organizational opinion on what web development framework to use (when we have a choice in the matter). -In making a choice we're seeking to match up the tradeoffs that the tools provide with projected partnership needs. The technical ecosystems we operate in tend to change often, so this is a decision we should seek to re-evaluate at least annually. Some topics to consider in the decision include: +In making a choice we're seeking to match up the tradeoffs that the tools provide with projected partnership needs. The technical ecosystems we operate in tend to change often, so this is a decision we should seek to re-evaluate at least annually. Some topics to consider in the decision include (but not limited to): - Accessibility for junior engineers. - Support for rapid prototyping. @@ -16,115 +16,72 @@ In making a choice we're seeking to match up the tradeoffs that the tools provid - Batteries included vs. things we have to roll ourselves. - e.g authentication and authorization tooling, data model management, caching, etc -(this list is likely not complete, feel free to modify or add to it as we put this draft together) - The decision outcome does not need to be a single framework. Ideally we'll choose 2-3 that we would ask folks to choose from in most scenarios. -## Decision - -Put a decision outcome here when ready. - ## Why is this applicable to the Practice as a whole? A large portion of our work is focused on developing web apps in partnership with public and private organizations. Each time something new starts we need to make decisions about how we'd like to approach it. This is meant to help give guidance in order to lower the burden of that choice. Having a 'practice opinion' on these tools will also help support folks' professional development, as well as our hiring and on-boarding processes. As we hire and get folks up to speed, this decision may be able to help us tailor what we do toward 'what we're trying to be good at.' Similarly we could lean on this as we seek to provide resources for folks developing their professional development plans. -## Alternatives Considered - -### Django - -#### Pros - -- `+` Mature framework that's been around since 2005. -- `+` Opinionated tooling for managing data migrations, potentially making the task more accessible for junior practitioners. -- `+` Strong ORM allowing the abstraction of many database interactions. -- `+` Features designed to make form creation and management easier. -- `+` Strong templating tooling -- `+` Possible to gain a portion of the features typically associated with single page applications, with less overhead by pairing the framework with something like [htmx](https://htmx.org/). -- `+` Uses the python programming language which enjoys broad community support, and is useful across multiple subpractices like web development and data science. -- `+` Provides batteries included tooling for authentication and authorization, caching, and an administrative console, among others. These make it easy to create a secure REST API quickly, making it a great option for rapid prototyping. -- `+` Uses Python, which is considered easy to learn and is now frequently taught in both college and bootcamp programs. -- `+` Strong community support -- `+` Built-in Admin interface is useful for having a UI to interact with project database - -#### Cons +## Framework Evaluation -- `-` Different languages between backend and frontend if Javascript is needed for client interactions. -- `-` May need to use additional tooling for asynchronous workload use cases (message queues and workers). -- `-` Python's dynamic typing may lead to more effort spent on unit tests. But this can be mitigated some through [type hinting](https://docs.python.org/3/library/typing.html) -- `-` Since Django is highly opinionated, if you're new to it it'll seem like there's a lot of "magic" under the hood. Compared to smaller frameworks like Flask the learning curve can be steep. -- `-` Django is a REST framework, so it doesn't have great websocket support. -- `-` Limitations around async support, with potential performance implications. More on this in the [Django async documentation](https://docs.djangoproject.com/en/4.2/topics/async/). -- `-` Opinionated toward monolithic apps, may not be a good choice for microservices use cases. +### Back-End Frameworks -### Spring +#### Django (Python) -#### Pros +- **Pros**: Mature, “batteries included,” excellent for rapid development, robust ORM, strong security features. +- **Cons**: Monolithic, less flexible for non-standard requirements, limitations around async support, high learning curve compared to smaller frameworks, dynamic typing is prone to more errors. +- **Accessibility**: Uses Python which is considered easy to learn and suitable for juniors, strong community support, robust documentation. -- `+` Mature framework that's been around since 2002. -- `+` Reactive programming model could be useful for a variety of use cases. -- `+` Spring boot is good for microservices where use cases call for that. -- `+` Batteries included tooling for things like authentication and authorization and caching, among others. -- `+` Java tooling is popular in enterprise spaces -- `+` Uses Java, which is commonly taught in college programs. -- `+` Java is statically typed which can give safety that would otherwise be gained through additional unit tests. +#### Spring Boot (Java) -#### Cons +- **Pros**: Mature, enterprise-grade, scalable, good for microservices, static typing. +- **Cons**: Steeper learning curve, more configuration required, less suitable for rapid prototyping. +- **Accessibility**: Uses Java which is commonly taught in college programs, although notably more verbose than Python and Javascript. -- `-` Big complex framework with a lot of capabilities, but may be less suited for rapid prototyping use cases. -- `-` Different languages between backend and frontend if Javascript is needed for client interactions. -- `-` Potentially too many features, need solid understanding of the framework to know what's most useful. Effort needed to keep team(s) in alignment on practices. -- `-` Potentially verbose configuration -- `-` Might have a steep learning curve for some, making it potentially more difficult to onboard junior practitioners. +#### Node + Express.js (Typescript) -### Express.js +- **Pros**: Mature, high flexibility, large ecosystem, strong community support, suitable for real-time applications. +- **Cons**: Requires more boilerplate, less guidance on structure. +- **Accessibility**: If we're abiding by prior ADRs it would mean using Typescript, which may have some learning curve for folks coming in without that background. -#### Pros +### Front-End Frameworks -- `+` Strong performance for event driven workloads -- `+` Strong community support -- `+` Uses Javascript, which is commonly taught in bootcamp programs -- `+` Flexibility in how applications are structured (not opinionated). -- `+` Mature framework that's been around since 2010. -- `+` Can use typescript with this framework, allowing us to keep with [ADR 0001](https://playbook.truss.dev/docs/appeng/adrs/use-typescript). +#### React.js -#### Cons +- **Pros**: Industry standard, high flexibility, strong community, large ecosystem, easily build cross-platform apps with React Native. +- **Cons**: JSX learning curve, more choices for state management, constant updates require developers to relearn newer concepts to keep up. +- **Accessibility**: Good for juniors with Javascript basics. -- `-` Not opinionated, this lack of structure can make it more difficult to keep team(s) on the same page around specific practices and approaches. -- `-` Minimialist framework, so lacking in some batteries included features, leaving projects to choose other tools to add on with it. -- `-` If we're abiding by prior ADRs it would mean using Typescript, which may have some learning curve for folks coming in without that background. +#### Angular -### Vue.js with Node.js +- **Pros**: Lots of tools provided out of the box, strong community, long-term maintainability since it’s backed by Google. +- **Cons**: No strong support for cross-platform apps. +- **Accessibility**: Requires skill in Typescript, which may have some learning curve for folks coming in without that background. -#### Pros +#### Vue.js -- `+` One programming language for both frontend and backend. -- `+` Node.js can be strong on concurrent request handling. -- `+` Considerable library/tooling support -- `+` Modular architecture can be useful for microservices -- `+` Strong community support +- **Pros**: Focuses on helping beginner developers create dynamic web apps without prior tedious learning. +- **Cons**: Smaller community, no strong support for cross-platform apps, doesn’t render in older versions of web browsers. +- **Accessibility**: Known for easy learning curve. -#### Cons +### Cloud Infrastructure Providers -- `-` Projects have to figure out security implementation, which could introduce additional risk. -- `-` Server side rendering is possible but may be complex to set up and use -- `-` The flexibility this combination allows for may also allow for complexity creep. -- `-` Dependency management and keeping both parts of the stack in sync may introduct additional overhead. +#### Amazon Web Services (AWS) -### React with Node.js +- **Pros**: Market leader in cloud services, suitable for small and enterprise scale, extensive documentation, large community and support, has the largest number of data centers. +- **Cons**: High learning curve, naming conventions tend to be confusing, user interface is not good. +- **Accessibility**: Amazon provides excellent online training resources for all levels. -#### Pros +#### Google Cloud Platform (GCP) -- `+` One programming language for both frontend and backend. -- `+` Node.js can be strong on concurrent request handling. -- `+` Considerable library/tooling support -- `+` Strong community support +- **Pros**: Excels in big data processing and ML, leading in Kubernetes and open-source integrations, focuses on high-performance networking and low-latency connections. +- **Cons**: Fewer resources and community support compared to AWS. +- **Accessibility**: Slightly more accessible due to focus on open-source and user-friendly interfaces. -#### Cons +#### Microsoft Azure -- `-` Projects have to figure out security implementation, which could introduce additional risk. -- `-` React can have a steep learning curve when coming from other frameworks. -- `-` Server side rendering is possible but may be complex to set up and use -- `-` The flexibility this combination allows for may also allow for complexity creep. -- `-` Dependency management and keeping both parts of the stack in sync may introduct additional overhead. +- **Pros**: Robust offerings in AI and ML due to Microsoft’s partnership with OpenAI, integrates with Microsoft ecosystem. +- **Cons**: High learning curve, not as good customer service. +- **Accessibility**: High learning curve. \ No newline at end of file From 8517000f9bacf1045644b7c4818ce16c101c3f1f Mon Sep 17 00:00:00 2001 From: Melissa Thai Date: Wed, 17 Jan 2024 15:52:42 -0800 Subject: [PATCH 9/9] pre-commit --- docs/appeng/adrs/0006-web-development-framework-preference.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/appeng/adrs/0006-web-development-framework-preference.md b/docs/appeng/adrs/0006-web-development-framework-preference.md index ae7a708f..c3c4da11 100644 --- a/docs/appeng/adrs/0006-web-development-framework-preference.md +++ b/docs/appeng/adrs/0006-web-development-framework-preference.md @@ -84,4 +84,4 @@ Having a 'practice opinion' on these tools will also help support folks' profess - **Pros**: Robust offerings in AI and ML due to Microsoft’s partnership with OpenAI, integrates with Microsoft ecosystem. - **Cons**: High learning curve, not as good customer service. -- **Accessibility**: High learning curve. \ No newline at end of file +- **Accessibility**: High learning curve.