bedrock
bedrock copied to clipboard
mozilla
[Epic] Move interaction with basket to client side where possible
Description
Currently newsletter signups and the email preferences center all interact with basket via bedrock's backend servers. There isn't a good reason for this for the most part. We should update our newsletter subscription forms and the email prefs center to interact directly with basket via JS rather than submit to bedrock which then just redirects the data to basket. This would reduce the load on bedrock's servers and allow for better caching by the CDN.
Success Criteria
- [x] https://github.com/mozilla/bedrock/issues/11944
- [x] https://github.com/mozilla/bedrock/issues/11945
- [x] https://github.com/mozilla/bedrock/issues/11963
- [ ] https://github.com/mozilla/bedrock/issues/11946
Depending on how far we want to take it, the outcome of https://github.com/mozilla/bedrock/issues/10566 might be a good candidate for the email preference center.
@pmac As https://github.com/mozilla/bedrock/issues/11120 is p2 and this is p3, I think work on #11120 should start sooner. Agreed?
Yes. For sure. Agreed. I just wanted to get this into the backlog so we don't forget it.
Follow up to https://github.com/mozilla/bedrock/pull/11234#pullrequestreview-896323896
Front-end note: might need to hide or provide better error feedback for users trying to submit forms without JS
@pmac if we're going to move the preference centre to use JS, we'll first need an API we can query that can return someone's preference data. Is that something that already exists somewhere, or should we file a dependency issue to create one?
It does. Same one the backend currently uses to fetch it from basket.
Is this endpoint documented anywhere?
Found the basket docs: https://basket.readthedocs.io/newsletter_api.html
Yeah, the docs aren't great, but these are they https://basket.readthedocs.io/newsletter_api.html#news-user
The way it works is that once you have the user's token from the URL, you can use it in a URL like the one below to get a JSON response with their info:
https://basket.mozilla.org/news/user/4a3bd4e1-fc01-490d-98e3-0a7305ff6a33/
That token is one I just created as an example. You are welcome to mess with it to see how the data works.
Thanks! I think turning this into an epic and then filing smaller issues for the individual parts you mention in the description above makes sense.
Digging into the "where possible" part a little, are there any other things we should cover here? Or can't cover? I notice there's the email recovery page too. Is that something that requires an API key?
The recovery page does not require an API key, so we can include that as well.
Another aspect is that this presents us with an opportunity to rethink even more of the user experience and what data we store and request. For example:
We currently only store the user's language preference as a single data point. We could in theory store a language preference for the user per newsletter since each newsletter is available in a potentially different list of languages and a user might be okay with receiving English for one but would prefer to receive French for another for which that is available. This would require work on the CTMS side as well, and potentially in Acoustic, but I believe it is possible now that we have CTMS and not our old contact storage system.
This would be a sizable expansion of scope, so we may not want to pursue this now, but it might be a good time to explore the UX of the email prefs center page with possibilities like this in mind.
This would be a sizable expansion of scope, so we may not want to pursue this now, but it might be a good time to explore the UX of the email prefs center page with possibilities like this in mind.
Yeah, let's see how it goes. But my gut says this might be a good post-migration improvement.