You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Doing all the filtering only on client-side has some downsides.
It's harder to implement some features because the app doesn't have all the data available locally or in the server, and GitHub API V3 doesn't support filtering.
Short term workaround
Fetch everything on the client, like, all notifications and all events possible. Not a good solution, it could affect performance, would require some wait time to download everything on each device, would not have access to the whole history of notifications/events since GitHub stops returning old ones.
Solution
Move everything to the server. It would unlock indefinite possibilities of what I can do with the data. Specially:
Better filters
Integrations like Push Notifications, Slack, etc.
Store older data instead of the short 7-day window that GitHub returns.
Easier sync of everything between all devices, like saved items, unread state of events, etc.
Increased security (token would never be exposed client side)
Cons:
Increase of database size and server bandwidth = increase of costs (might fetch millions of notifications+events).
May take some time do it. Might need to migrate from redux+axios to something like Apollo/Relay to easily handle caching and subscriptions.
Some companies may not like the idea of having their private repos activities saved in DevHub's database(although doesn't make much difference because the token itself would already give access to this)
Not sure but this may hurt a possible GitHub Enterprise support in the future. Seems to be easier the way it is today.
Bonus points
Realtime sync between all devices. Great combo if using the GitHub webhooks and GraphQL subscriptions.
Considerations
If GitHub API V4 (GraphQL) supported the Notifications and Events API, maybe this wouldn't be necessary. And they may add support for them "soon".
The text was updated successfully, but these errors were encountered:
Doing things locally is ok, what we need is a proper client Database instead of local storage, and also a proper sync with the backend. No need to move everything to the server.
Problem
Doing all the filtering only on client-side has some downsides.
It's harder to implement some features because the app doesn't have all the data available locally or in the server, and GitHub API V3 doesn't support filtering.
Short term workaround
Fetch everything on the client, like, all notifications and all events possible. Not a good solution, it could affect performance, would require some wait time to download everything on each device, would not have access to the whole history of notifications/events since GitHub stops returning old ones.
Solution
Move everything to the server. It would unlock indefinite possibilities of what I can do with the data. Specially:
Cons:
Some companies may not like the idea of having their private repos activities saved in DevHub's database(although doesn't make much difference because the token itself would already give access to this)Bonus points
Considerations
If GitHub API V4 (GraphQL) supported the Notifications and Events API, maybe this wouldn't be necessary. And they may add support for them "soon".
The text was updated successfully, but these errors were encountered: