Skip to content
92 changes: 92 additions & 0 deletions docs/appeng/adrs/0006-web-development-framework-preference.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,92 @@
# 0006 - Preference for x as web development framework(s)
Copy link
Copy Markdown

@melissathai melissathai Dec 6, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we also want to compare other aspects of webdev, such as databases (MySQL vs Postgres vs all the flavors of noNQL), APIs (REST vs GraphQL), CI/CD (Jenkins, CircleCI, etc), cloud infrastructure (AWSvs Azure vs GCP)?


**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

### 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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggestion: Django also has a dedicated security team, which not all frameworks have.

#### 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
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One more pro - same language between backend and frontend.


- `+` 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.