Choice of backend framework

[seporterfield]

Choice of backend framework

• Impact: 🔴 Major
• Status: 🔓 Awaiting decision...

• Deciders & Confidence:

  • @purple-void (3.5/5)
  • @seporterfield (5/5)
  • @Monstarrrr (5/5)

Context

Rebutify's backend will primarily serve API endpoints. What framework will we use for Rebutify's backend?

Decision Drivers

• Compatibility with team
• API functionality
• Support (official and unofficial)
• Already completed Rebutify MVP features in ecosystem
• Scalability

Considered Options

Ruby on Rails

Ruby on Rails

• :orange_circle: [Compatibility with team]

  • there are no ruby or ruby on rails developers on our team. Slowdown caused by this would be on the magnitude of months.

• :green_circle: [Already completed Rebutify MVP features in ecosystem]

  • QPixel is almost a complete Rebutify MVP

• :orange_circle: [Scalability]

  • Using QPixel would have kept us locked into a monolith architecture.

Django

Django

• :green_circle: [Compatibility with team]

  • 2/3 of our team members have experience with python, one with python as a strong suit and previous experience with Django

• :green_circle: [API functionality]

  • Django has the Django Rest Framework (DRF), which makes it easy to write APIs

• :green_circle: [Support]

  • python is the most popular programming language only second to javascript (stackoverflow survey 2023). This means excellent community support, and easier onboarding for project longevity
  • Django is the most popular python framework (and # 14 python library on GitHub) (github top 100 python)

• :orange_circle: [Scalability]

  • In the specific case the frontend is also Django, via templates and non-DRF views, using a monolith architecture will make our architecture tightly coupled and therefore less easily scalable, since tightly coupled components cannot be scaled separately.

Next.js

Next.js

• :green_circle: [Compatibility with team]

  • 2/3 of our team members have javascript as a strong suit

• :green_circle: [API functionality]

  • native API functionality with API routes

• :green_circle: [Support]

  • Next.js was the number 1 javascript fullstack framework according to the stateofjs report in 2020. Despite the changing world of javascript development there is rich support and documentation for Next.js due to this.

• :orange_circle: [Scalability]

  • In the specific case the frontend is also Next.js, using a monolith architecture will make our architecture tightly coupled and therefore less easily scalable, since tightly coupled components cannot be scaled separately.

Decision Outcome

Chosen option: Django Reason: Django was chosen due to its strong compatibility with the team's existing skills, its robust API functionality through the Django Rest Framework, and the extensive community and support available, ensuring ease of onboarding and long-term project viability. The fact that something other than Django is more suitable for the frontend gives us the opportunity to choose Django for the backend and split the architecture in a more scalable way.

[Monstarrrr]

I'd add nextjs as an option and scalability as a decision driver

[seporterfield]

Done. Does it look correct?

[Monstarrrr]

What i'd update

Django

Maybe no need to mention frontend as this is only about backend?

• Better scalability
  • Can do much heavier tasks than JS frameworks
• Worse scalability
  • Dynamic typing can lead to code that is harder to understand and maintain (because python is not strong typed)

Nextjs

• Worse scalability

  • Backend engineering is Next.js' biggest weakness. There is really no comparison with a mature web framework like Spring, Laravel, Django etc. In mature web frameworks you have multiple abstractions for organizing your backend code and separation of concerns. In Next.js, Vercel gives users "Server Actions" and make it sound like they just invented sliced bread. Also in Next.js, everything is a la carte - will need to bring your own serialization, orm, migrations and much much more. Also you will have to bring your own patterns for organizing lots of backend business logic. Which basically means your large backend codebase will be a special snowflake.

[seporterfield]

Not sure about the workload claim. Especially for a website that we can scale horizontally.

Default python is strongly typed and dynamic. Using mypy, python is statically typed.

[seporterfield]

Maybe no need to mention frontend as this is only about backend?

How our choice of backend plays into the overarching architecture is important.

I don't see how we can avoid talking about other components in that architecture and how they would be affected and the restrictions they set on our choice of backend framework.

[Monstarrrr]

Maybe no need to mention frontend as this is only about backend?

How our choice of backend plays into the overarching architecture is important.

I don't see how we can avoid talking about other components in that architecture and how they would be affected and the restrictions they set on our choice of backend framework.

You're right, should we reference the dependencies and impact then?

Example

File for Decision-B in the case where Decision-C & Decision-D are dependent on Decision-B and Decision-B is dependent on Decision-A :

Decision-B.md (Frontend framework)

## Impacts
- #42 (Decision-C): API fetching method
- #55 (Decision-D): State management
## Dependencies  
- #30 (Decision-A): Backend framework

---

How maintainable would that be though?

[Monstarrrr]

^ Moved discussion on dependencies to #187

[Monstarrrr]

Added my confidence level