Technical Story: Spike Document

Context and Problem Statement¶

In order to be able to allow customers to use a mobile app, we need a way to authenticate that the user is a customer and has booked onto a guaranteed departure. Before this proposal, the only place that customer bookings are stored is in the Booking Engine. As the Itinerary for the mobile app comes from the backed, the user will also need to be authenticated against our backend.

Decision Drivers¶

• We want to be able to authenticate users against our backend
• We need access to the Booking Engine data to verify that users are booked onto a departure.
• Users already have an account on the marketing site - another Flashpack password for them to remember would be confusing.
• Working with the Booking Engine / Dan can be time consuming and difficult.
• 3rd party app store testers also need to be able to authenticate against this system.

Considered Options¶

Data¶

• Log into the Booking Engine Postgres directly
• Get the Booking Engine data via a Cloud Function calling the Booking Engine API data dump
• Use Estuary to sync the Booking Engine data to our backend

Authentication¶

• Use a custom token for login
• Have users be given a one time password via Email
• Have users login using an email and password
• Have users login using their phone number
• Use the same Magic Link authentication as the AM
• Use the same authentication as the marketing site / Booking Engine

Decision Outcome¶

Data¶

Chosen option: "Use Estuary to sync the Booking Engine data to our backend", because this gives us a fast way to get the data we need, and allows us to use the data elsewhere in the future.

Positive Consequences¶

• We have access to the tables in our DB without having to write custom code.
• We can use the data in other places in the future.
• We don't have any dependency on Dan / the Booking Engine to implement an API endpoint for us.

Negative Consequences¶

• We have to pay for Estuary
• The Booking Engine schema does not match 1:2:1 with ours (e.g. Tour Code vs Adventure Code)
• We have a dependency on Estuary / Data Team

Authentication¶

Chosen option: "Have users be given a one time password via Email". This gives us a way to authenticate users without having to store passwords in our database. In doing so, we can also give access to the app store testers.

Pros and Cons of the Options¶

[Log into the Booking Engine Postgres directly]¶

• Good, because we don't duplicate data.
• Bad, because the Booking Engine is currently a black box.
• We'd need to maintain multiple database connections in our app, which isn't necessarily a problem but it does introduce some complexity.

[Get the Booking Engine data via a Cloud Function calling the Booking Engine API data dump]¶

• Good, because we don't have a dependency on Dan / the Booking Engine.
• Good, because we don't have a dependency on Estuary / Ester.
• Bad, because we'd have to build a custom API to get the data from the Booking Engine.
• Bad, because the Booking Engine is currently a black box.

[Use Estuary to sync the Booking Engine data to our backend]¶

• Good, because this is all built for us.
• Bad, because we have to pay for Estuary.
• Bad, because we have a dependency on Estuary / Ester. (and Esturary is a very small startup)

Authentication¶

Technical Flows

[Use a custom token for login]¶

• Good, because it's quick to implement.
• Good, because Firebase supports this OOTB.
• Bad, because there's no secure way to email this to testers.

[Have users be given a one time password via Email]¶

• Good, because of all the same reasons as a custom token.
• Good, because we can email this to testers.
• Good, because it looks cleaner than emailing a JWT to users.
• Bad, because it takes slightly longer to build.

[Have users login using an email and password]¶

Stored in Firebase

• Good, because it's easy to implement.
• Bad, because users already have a password for the booking engine
• Bad, because we'd have to become account admins for people who need password resets.

[Have users login using their phone number]¶

• Good, because it's easy to implement (Firebase supports this OOTB)
• Bad, because the Booking Engine data is totally unsanitized and often times nonsensical.

[Use the same Magic Link authentication as the AM]¶

• Good, because we get to use the same system as the AM
• Bad, because this requires deep-linking inside of Capacitor, which adds a lot of development time.

[Use the same authentication as the marketing site / Booking Engine]¶

• Good, because users get the same account for everything 'Flashpack'
• Bad, because we'd have to build a custom API to get the data from the Booking Engine.
• Bad, because the Booking Engine is currently a black box.