Closed Bug 880772 Opened 11 years ago Closed 10 years ago

Remove user data from app resources

Categories

(Marketplace Graveyard :: Code Quality, defect, P3)

defect

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 969433

People

(Reporter: cvan, Unassigned)

References

Details

We put user data in app resources, which makes the API responses impossible to cache based on their URLs.

This works, but I'd like to add code that on synchronous page loads on desktop makes a call to the API to get back a new list of ids to append to our list of developed/installed/purchased/reviewed apps.

https://github.com/cvan/fireplace/compare/fast
https://github.com/cvan/zamboni/compare/fast

This will be so amazing. You have no idea. You think you don't, but you don't.
I don't want this to land until we've figured out all the issues we talked about offline, namely:

- Account changes never getting synced across devices without polling the server (it's like a client-side cache machine hell)
- Requiring you to relog to see that you submitted an app (and prevent the user from trying to review their own app)
- Requiring the user to log out and log back in (or wait until the device polls the server) to see that an app purchase went through on a second device
- Users that left a review on desktop will not see that they left a review when the look on their phone until they relog or the device polls the server
I can already hear Krupa now: "I left a review on desktop but my phone is letting me leave another review. When I submit on my phone, it says that there was an error."

Why do you like making things hard for Krupa, cvan?
(In reply to Matt Basta [:basta] from comment #1)
> I don't want this to land until we've figured out all the issues we talked
> about offline, namely:
> 
> - Account changes never getting synced across devices without polling the
> server (it's like a client-side cache machine hell)

What kind of account changes? As it stands today user settings are in localStorage and this is already an issue until you logout and then log back in. Is this correct?

> - Requiring you to relog to see that you submitted an app (and prevent the
> user from trying to review their own app)

GMail does two XHRs every time I *focus* GMail to resync any changes that may have happened from another tab or device. We can easily request to the server on a synchronous page load on desktop for a new list of developed/installed/purchased/reviewed ids. That way the client is always getting an accurate list from the server. Would this work?

> - Requiring the user to log out and log back in (or wait until the device
> polls the server) to see that an app purchase went through on a second device

Would the approach above work here?

> - Users that left a review on desktop will not see that they left a review
> when the look on their phone until they relog or the device polls the server

This issue exists today, correct? And we can fix it with the approach below, yes?

(In reply to Matt Basta [:basta] from comment #2)
> I can already hear Krupa now: "I left a review on desktop but my phone is
> letting me leave another review. When I submit on my phone, it says that
> there was an error."
> 
> Why do you like making things hard for Krupa, cvan?

Right now if I leave a review on desktop and go to mobile, the button will still say "Write a Review" even though I already wrote a review. Because we have a cached API response, I have to relaunch the Marketplace app for that button to show the correct state.
(In reply to Christopher Van Wiemeersch [:cvan] from comment #3)
> What kind of account changes?

I mean any of the user data that's being moved out of the app objects in the API.

> GMail does two XHRs every time I *focus* GMail to resync any changes that
> may have happened from another tab or device.

Actions in Gmail are also idempotent, which isn't the case for our API or our app state (unfortunately?).

> We can easily request to the
> server on a synchronous page load on desktop for a new list of
> developed/installed/purchased/reviewed ids. That way the client is always
> getting an accurate list from the server. Would this work?

One more HTTP request on load is going to be that much more overhead and block the splash screen. It'll also cause duplicate data in the case that Persona decides it's going to give you a new assertion and re-log you in as it tends to do (meaning you download the list of user data twice per synchronous load).

> This issue exists today, correct? And we can fix it with the approach below,
> yes?

> Right now if I leave a review on desktop and go to mobile, the button will
> still say "Write a Review" even though I already wrote a review. Because we
> have a cached API response, I have to relaunch the Marketplace app for that
> button to show the correct state.

It only happens if you have visited the app detail page (in the instance of reviews) or the ratings page (if you were deep linked). In that case I'm not sure that there's an expectation that we'd live-update the content.

If we're relying on a separate list of IDs that are tied to login rather than session, the issue will persist across sessions (until your device pings the server for a list of updates).
Priority: -- → P3
I think this could have a nice effect on API performance and impact a lot of users.

Besides user data (installed, purchased, developed, and reviewed IDs) we would also need to move out the price data since it's tied to the user's region. One solution there would be to have an API endpoint for prices per region that fireplace can get and cache hard (persist between launches). Then the app resources and search can simply return the price tier and fireplace convert that to a displayable price based on the cached mapping of price tier + region to currency.

Is it possible to use something like server sent events to tell fireplace when it needs to refetch user data?

We could also defer the loading of user data, correct? The homepage has no install buttons where you need this data to block the display of anything.

+1 on this happening.
(In reply to Matt Basta [:basta] from comment #4)>  
> > We can easily request to the
> > server on a synchronous page load on desktop for a new list of
> > developed/installed/purchased/reviewed ids. That way the client is always
> > getting an accurate list from the server. Would this work?
> 
> One more HTTP request on load is going to be that much more overhead and
> block the splash screen. 

Why would that block the splash screen, can't that fixed up after the page load. We can determine if the app is paid, needs installing, is launchable from the app data and the local API. So the use case is when someone has bought the app somewhere else since we got the user data. Post loading a small request to get that and update the page and user data. If users used e-tags (see other bugs) this would be quite a quick check.

There could be some UX work such as showing a banner if there's a discrepancy but I'm sure UX could help us on that.
(In reply to Rob Hudson [:robhudson] from comment #5)
> I think this could have a nice effect on API performance and impact a lot of
> users.

I think the gain will be positive and outweight the costs for what will be a small number of edge cases. I expect 99% of apps to be free and a small number to be paid. We should be optimizing for the majority of users.
(In reply to Andy McKay [:andym] from comment #6)
> Why would that block the splash screen, can't that fixed up after the page
> load

If we show the list of apps to the user, then four or five seconds later we switch the buttons from $0.99 to Install, that's going to be a really bad user experience. If the request fails (bad connection, 500, etc.), the user is going to be like, "WTF, I purchased this app. Why is it asking me to purchase it again?"

> We can determine if the app is paid, needs installing, is launchable
> from the app data and the local API.

That's not true for purchased but not installed apps, or apps that were purchased on other devices, or for users that purchased apps in the browser and then visited the app version of the Marketplace. Or for users that have installed apps but subsequently uninstalled them.

This is a case where the edge cases really do matter.
(In reply to Matt Basta [:basta] from comment #8)
> This is a case where the edge cases really do matter.

Edge cases do matter, but designing everything around edge cases leaving the main flow slower for everyone else isn't great. You describe edge cases that occur under very specific circumstances - things that should be accounted for.
(In reply to Andy McKay [:andym] from comment #9)
> Edge cases do matter, but designing everything around edge cases leaving the
> main flow slower for everyone else isn't great.

Universally making *everyone's* experience slower by requiring extra requests to synchronize when and where apps have been purchased, installed, reviews have been left, apps have been submitted, region has changed, and preferences have been updated is even worse. I completely agree that making the API more cacheable will increase performance. But when that second or third request to update user data takes an extra ten seconds because it contains 100kb of data and blocks the Marketplace from hiding the splash screen (or adds a second splash screen because we need to check to see if anything changed while the app was out of focus), we haven't made anything faster at all, we've just moved the slowness around. Sacrificing user experience in the name of a relatively small speed boost is unacceptable no matter how you slice it or how edge-casey the edge cases are.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.