ADR - Architecture Decision Records #225
Conversation
| We need to record the architectural decisions made on this project. Architectural Decision Records as | ||
| [described by Michael Nygard](https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions) provides a | ||
| framework for writing down these decisions. | ||
|
|
There was a problem hiding this comment.
I think it would be more understandable if we give some context as to why we are starting the ADR now. Maybe we could write that the ADR has been started at a point where the project has been running for several years but this seemed to be the right time because the project has evovlved to become more complex and that there are more developers involved than previous. This calls for summarizing some of the baselines of the project so we make sure to keep some of the original thoughts and decisions in the project documented and so that we remember to note if we make any changes as we move forward.
| This will make the system more future-proof. | ||
|
|
||
| [OpenAPI](https://www.openapis.org/) is a standard for describing an API interface. | ||
|
|
There was a problem hiding this comment.
As I understand it one of the great benefits of the API first approach also is that it is possible that content can be delivered from another admin/contentplatform than the OS2Display admin - maybe that is worth noting here
|
|
||
| By versioning the API we can communicate changes in the API. If an endpoint changes in a way that breaks backwards | ||
| compatibility we will change the route version. An example of a backwards compatibility break is changing field names. | ||
|
|
There was a problem hiding this comment.
Is it necessary to say that we use sem or simver?
There was a problem hiding this comment.
We do not use semver for routes. We use /v1, /v2, etc prefix for routes.
|
|
||
| The browser sets sandboxing constraints on the application when running in a browser. | ||
|
|
||
| The benefit is that that client should be able to run on most environments. |
There was a problem hiding this comment.
Also one of the benefits as I see it is that the browser is a user friendly medium and easy to interact with and understand from a configuration point of view. This makes it easier to set up a screen
docs/adr/007-configurability.md
Outdated
| ## Consequences | ||
|
|
||
| Features that are not "core" will have to be implemented as configurable wherever possible. | ||
| This will introduce extra work when implementing features. |
There was a problem hiding this comment.
Also one of the more negative consequences will be that you potentially have an amount of the application code as a "dead" part, maybe this will also have some negative influence on performance?
There was a problem hiding this comment.
I don't think there is a big negative impact on performance. But it will make the application code more complex, every time extra configuration is added.
Link to ticket
https://leantime.itkdev.dk/#/tickets/showTicket/2770
Description
Adds ADRs.