mirror of
https://github.com/opencloud-eu/opencloud.git
synced 2025-12-20 03:19:53 -06:00
2.1 KiB
2.1 KiB
status, date, author, decision-makers, consulted, informed, title, template
| status | date | author | decision-makers | consulted | informed | title | template |
|---|---|---|---|---|---|---|---|
| proposed | 2025-06-25 | Pascal Bleser <p.bleser@opencloud.eu> | Groupware Software Stack | https://raw.githubusercontent.com/adr/madr/refs/tags/4.0.0/template/adr-template.md |
- Status: draft
Context
Which software stack to choose for the implementation of the OpenCloud Groupware service?
Considered Options
- Go with the OpenCloud framework, as it is used in OpenCloud
- Rust, as it is a similarly modern language, with know-how in Opentalk
- Java with an opinionated microservice framework (e.g. Micronaut)
Decision Outcome
The decision was taken to go with the existing Go technology stack used in OpenCloud, since it allows for
- everyone in the Groupware backend team to contribute
- having a single technology stack across all OpenCloud backend features
- having the option of a single binary deployment
Consequences
TODO
Confirmation
TODO
Pros and Cons of the Options
Go
- good: established in the OpenCloud team, with expertise, potentially broadening the team that can contribute to Groupware development
- good: make use of the existing infrastructure and framework, including the single binary deployment option
- bad: less mature and capable technology stack, potentially problematic with regards to lack of asynchronous I/O and streamed HTTP processing
Rust
- good: shared knowledge with the team of developers at OpenTalk
- bad: little to no experience in the current OpenCloud team
Java
- bad: little to no experience in the current OpenCloud team, with exception of the Groupware members
- good: extensive experience with Micronaut with one OpenCloud developer
- good: opinionated and well documented
- good: cloud native
- good: mature technology stack
- good: asynchronous I/O and virtual threads make for efficient resource usage
- potentially bad: likely to not fit well into low resource environments (although native compilation using GraalVM is possible)
- potentially bad: prevents the single binary deployment option from including Groupware