Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: support metaphysics CDN and support cacheable #10842

Merged
merged 7 commits into from
Sep 26, 2024

Conversation

MounirDhahri
Copy link
Member

Description

This PR makes the following changes:

  • Add MP CDN support to Eigen
  • Support our custom Graphql @cacheable directive
    Both changes are hidden behind a feature flag

Open questions:

  • Currently I am deleting the access token for cacheable requests. I worry though that a query might grow into becoming non-cacheable (for example after adding Me) and the request will fail and there is nothing we can do to solve it from the CDN level. A retry strategy here seems like a requirement to me here 🤷
  • useLazyLoadQuery sets force to true always by default. Should we mimic that for network queries like in Force?
  • I noticed that query persistence logic in Eigen was "broken" - it always led to an additional request. Does it make sense to keep it? what measurable performance improvement does it bring?

PR Checklist

  • I have tested my changes on iOS and Android.
  • I hid my changes behind a feature flag, or they don't need one.
  • I have included screenshots or videos, or I have not changed the UI.
  • I have added tests, or my changes don't require any.
  • I added an app state migration, or my changes do not require one.
  • I have documented any follow-up work that this PR will require, or it does not require any.
  • I have added a changelog entry below, or my changes do not require one.

To the reviewers 👀

  • I would like at least one of the reviewers to run this PR on the simulator or device.
Changelog updates

Changelog updates

Cross-platform user-facing changes

iOS user-facing changes

Android user-facing changes

Dev changes

  • support metaphysics CDN and support cacheable - mounir

Need help with something? Have a look at our docs, or get in touch with us.

@mzikherman
Copy link
Contributor

Currently I am deleting the access token for cacheable requests. I worry though that a query might grow into becoming non-cacheable (for example after adding Me) and the request will fail and there is nothing we can do to solve it from the CDN level. A retry strategy here seems like a requirement to me here

If so - wouldn't a dev notice in development that their query doesn't work? As in, they have a cacheable query. Then, they add a fragment that depends on access token (like something scoped under me). Once they do that...that query wouldn't return the right data, the access token would have been removed and so their personalized fragment they added wouldn't resolve. I feel like the dev would notice. (that being said we can think about tooling/validations to improve dev workflow).

@MounirDhahri
Copy link
Member Author

That's actually a good point @mzikherman - I can add some dev tooling to make sure that the error thrown shows a hint about @refetchable ;)

@MounirDhahri MounirDhahri force-pushed the feat/support-cacheable-in-eigen branch 2 times, most recently from 0ba89d2 to b7af2c9 Compare September 25, 2024 13:40
}
body = { query: require("../../../../../data/complete.queryMap.json")[queryID], variables }
req.fetchOpts.body = JSON.stringify(body)
return await next(req)
Copy link
Contributor

@brainbicycle brainbicycle Sep 25, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

are we no longer using the persisted queries?, oh just saw your comment, I think it works when the query map in eigen is in line with MP? I could be wrong but think it works some time. I am not sure about how beneficial it actually is though, it does annoy me when trying to debug but could be a consequential change we should probably test.

Copy link
Member

@damassi damassi Sep 25, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am 100% in favor of removing this for the time being 👍 I feel like our concern for low powered devices is unwarranted given our demographic, and in any case, is trivial.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This also vastly improves the developer experience, sentry experience, and so on and so forth. Its worth it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i am not opposed to it but I don't want us to just assume it will have no effect, the app is chatty and the bandwidth might add up, I think at least we should try to understand what the impact might be and monitor.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point on Eigen being chatty @brainbicycle - Let me see if I can keep this then we can remove it in a separate PR. Here I deleted it because:

  1. I wanted to reproduce the experience on a production device as close as possible
  2. I wanted some to evaluate the improvement in latency
  3. I am not sure what will be the synergy like between the CDN and MP using the persisted queries 🤷 but I guess it will work out of the box 👀

@MounirDhahri
Copy link
Member Author

MounirDhahri commented Sep 25, 2024

Interesting results with the CDN

Query name MP CDN -> MP CDN
HomeViewQuery 335ms Cell 320ms-370ms
HomeViewSectionActivity 415ms 475ms X
HomeViewSectionArtworks 452ms 515ms X
HomeViewSectionHeroUnits 256m X 113ms
HomeViewSectionGalleries 248ms X 274ms

Note: these are values from staging, I assume in production the impact will be greater!

@MounirDhahri MounirDhahri marked this pull request as ready for review September 25, 2024 16:03
}

// Helper method that returns the current URL
export const getCurrentURL = () => {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am glad I managed to use this helper that I spent hours to write at the beginning of the year

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not necessarily for this PR, but it would be great to separate this stuff out. In force, etc, we have a

src/system/router

folder, and then inside that we should store utils related to the router

src/system/router/utils

Then all of the implementation details for our router can go in there, and our routes file can remain clear and behavioral.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good idea - that should be fast to do. I will do it

@ArtsyOpenSource
Copy link
Contributor

ArtsyOpenSource commented Sep 25, 2024

This PR contains the following changes:

  • Dev changes (support metaphysics CDN and support cacheable - mounir)

Generated by 🚫 dangerJS against b1db98b

@@ -13,7 +13,11 @@ import { useTracking } from "react-tracking"
import { ArticlesList, ArticlesPlaceholder } from "./ArticlesList"

export const Articles: React.FC = () => {
const queryData = useLazyLoadQuery<ArticlesQuery>(ArticlesScreenQuery, articlesQueryVariables)
const queryData = useLazyLoadQuery<ArticlesQuery>(ArticlesScreenQuery, articlesQueryVariables, {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What we've done in Folio is define a useSystemQueryLoader that encompasses this kind of default behavior, and then leaned on that: https://github.com/artsy/energy/blob/main/src/system/relay/useSystemQueryLoader.tsx.

As we're changing global behavior, we should hide as much implementation detail stuff as possible behind an artsy-specific API, and then evangelize that 👍

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your feedback. Sorry for not answering this earlier. I think your comment here makes total sense. I was wondering why you went that direction in Force and in Folio but I think that's more future proof especially in cases like this where we want to update the behaviour in multiple screens.
This actually reminded me of this talk that I watched recently where the speaker is raising a good point about using your own hooks around state library / in our case this applies to relay hooks perfectly https://youtu.be/KI9xTG6wpeY?si=DR8Szsu3cr6EGnQm&t=379

? unsafe__getEnvironment().metaphysicsCDNURL
: unsafe__getEnvironment().metaphysicsURL

return metaphysicsURL
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

damassi
damassi previously approved these changes Sep 25, 2024
Copy link
Member

@damassi damassi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code looks good @MounirDhahri ! thanks for diving into this. One suggestion about using a useSystemQueryLoader hook and then updating various sections using that. From there we can continue building out a more specific API for relay operations in the app, from there.

@MounirDhahri MounirDhahri merged commit a4db61f into main Sep 26, 2024
7 checks passed
@MounirDhahri MounirDhahri deleted the feat/support-cacheable-in-eigen branch September 26, 2024 07:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants