Pull user favorite stops/routes from the cloud

[barbeau]

We currently have users set their current stop via the voice interface. In the future we will likely support having more than one favorite stored. Setting these via the voice interface is ok, but can be awkward. We also only currently support numeric stop_codes, as we use the numeric intent to recognize the speech. There could potentially be alphanumeric stop_codes for stops.

One option for improvement is to store the favorites in the cloud, and via OAuth pull them from another system for OBA Alexa.

From https://developer.amazon.com/public/solutions/alexa/alexa-voice-service/docs/authorizing-your-alexa-enabled-product-from-an-android-or-ios-mobile-app:

This document explains how to use the Login with Amazon SDK to enable your mobile Android or iOS app to pass the Login with Amazon OAuth 2.0 authorization code to an Alexa-enabled product so that the Alexa-enabled product can be authorized to access the Alexa Voice Service APIs on behalf of the authorizing user.

We're currently working with Microsoft on some social networking features for the OBA Android and iOS apps, so I'm going to see if we could leverage that platform to help bootstrap the favorites list.

[barbeau]

See also https://developer.amazon.com/public/solutions/alexa/alexa-skills-kit/docs/linking-an-alexa-user-with-a-user-in-your-system.

[philipmw]

Yeah this is definitely possible. I am wary of doing this because it has the potential to add friction to the user experience, and it's certainly more for us to maintain (new web application).

I'm curious whether the demand for multiple stops will be high enough to justify this. Does OBA have any existing metrics on this?

[barbeau]

I agree, if we implement I'd want to do with as little additional infrastructure as needed.

To my knowledge we don't have any info on how many stops users typically star on mobile apps, although I know that the Starred stops screen is one of the most frequently used screens. A better analogous case for Alexa may be web page bookmarks in each region (because they are more likely to be in a stationary position) but again, we don't have that data.

[barbeau]

More on Alexa OAuth:
https://developer.amazon.com/public/community/post/Tx2LK4MTIM3KAKC/Big-Nerd-Ranch-Series-Developing-Alexa-Skills-Locally-with-Node-js-Account-Linki

[bbodenmiller]

Did you all have any thoughts on implementing across the various platforms? I'd hope you if you set your favorite in the app (OneBusAway/onebusaway-android#32, does not appear to be iOS issue yet) it would also be reflected on your Echo but perhaps the Echo would ignore stops not in walking distance.

[barbeau]

I believe Firebase real-time database would be an option for cloud save across iOS and Android:
https://firebase.google.com/docs/database/

One question would be if there is a Java-based SDK for Firebase that our Echo skill could use to access the data. Second, given that it's a Google service, it may require Google Account - I haven't dug into the docs enough to know yet. I know this was a deal breaker at some of the dual platform systems we looked at earlier.

Cc @aaronbrethorst so he's aware of the option.

[aaronbrethorst]

Firebase would be fantastic, but I expect that the monthly fee would be prohibitive.

[barbeau]

From https://firebase.google.com/pricing/ for "Realtime Database":

SPARK (free) plan:

• Simultaneous connections = 100
• GB stored = 1 GB
• GB Transferred = 10 GB
• Daily private backups = NO

FLAME ($25/month) plan:

• Simultaneous connections = Unlimited*
• GB stored = 2.5 GB
• GB Transferred = 20 GB
• Daily private backups = YES

For FLAME Unlimited connections:

*Firebase imposes hard limits on the number of connections to your app's database at the same time. These limits are in place to protect both Firebase and our users from abuse.

The free plan limit is 100, and cannot be raised. The Flame and Blaze Plans have an initial limit of 10,000 simultaneous database connections. This is to prevent abuse and can be raised by contacting Firebase support with 24 hours notice.

This limit isn't the same as the total number of users of your app, because your users don't all connect at once. We encourage you to monitor your peak simultaneous database connections and upgrade if needed.

We're working hard to remove the initial 10,000 simultaneous connection cap on the Flame and Blaze plans.

Without running any numbers, I'm guessing that for something simple like storing the combination of userId and favorite stopIds we'd be able to squeeze into the FLAME package for $25/month. Free tier wouldn't work due to limited number of simultaneous connections at 100.

[aaronbrethorst]

Apologies for my lack of knowledge, but would ever concurrent user of the iOS, Android, web, and Alexa apps that are talking to the Firebase backend count as a Firebase simultaneous connection? i.e. if we have 10,000 people around the world that are simultaneously looking at OBA on their device, then the 10,001st user will see an error, regardless of what platform they're on?

[barbeau]

@aaronbrethorst You can ignore the 10,000 "simultaneous connection" cap for the FLAME $25/month plan - it's effectively unlimited. It sounds like the 10k cap is just an initial onboarding limit to prevent spamming/automating account creation:

This is to prevent abuse and can be raised by contacting Firebase support with 24 hours notice.

So upon initial OBA Firebase account setup, we'd call Firebase support, ask them to remove the 10k cap, and then going forward we'd have unlimited connections.

[aaronbrethorst]

OK, cool. In that case, I'm definitely 👍 on Firebase.