Technical Story: Linear Ticket

Context and Problem Statement¶

When preparing a build of the mobile application, we can choose which server url to communicate with, whether to communicate with a specific revision (release of the server) or to a service url (load balancer) which delegates calls to revisions based on traffic percentage, which one to choose?

Decision Drivers ¶

• We want to communicate with a stable server api
• We want to be able to roll out improvements/bugfixes to the app without requiring a new app release

Considered Options¶

• Connect to a specific revision of the adventure manager server
• Connect to the adventure manager server service url (load balancer)

Decision Outcome¶

Chosen option: Connect to the adventure manager server service url (load balancer), because this allows us to continuously roll out fixes to the server the app communicates with, even though it might also mean more chances of breaking the api as we roll out new server versions.

Positive Consequences ¶

• Ability to ship bug fixes / improvements without having the users upgrade the app
• Ability to roll back to previous versions in the event of an emergency / incident

Negative Consequences ¶

• With rolling out versions of the server almost every day (including adventure manager specific changes) the changes are getting bigger that we will introduce a regression bug
• We have to keep the graphql api backwards compatible and avoid breaking changes

Pros and Cons of the Options ¶

[Connect to a specific revision of the adventure manager server]¶

• Good, because the changes for a regression bug are significantly smaller
• Good, because we can introduce breaking changes more easily
• Bad, because in the event of an issue / bug, we will need to ask the users to upgrade the app in order to get the fix, which is unacceptable
• Bad, because we would have to maintain multiple revisions, which would be super hard because we have a single db for all revisions

[Connect to the adventure manager server service url (load balancer)]¶

• Good, because we are able to dynamically ship fixes to the server api
• Good, because we are able to easily manipulate the traffic to different revisions
• Bad, because the changes for a regression bug are greater
• Bad, because we have to keep the api backwards compatible for a while after a release