-
Notifications
You must be signed in to change notification settings - Fork 32
Description
Facebook do two clever tricks with their APIS:
- Never delete a field until you 100% know that nothing is using it anymore
- Log which fields are getting accessed and from where so you can help achieve point 1
Point one is sort of handled in #1 and this issue is about how we might achieve point 2. For now this one can be filed until "one day maybe" but its one of those features that just adds weight to the strength of this setup, if we can cover these sort of situations then it shows a forward thinking solution rather than a developers weekend coding scratch.
I'd suggest that we inject in some new middle ware that could initially just log a count of how many times each field is accessed. Ideally this would just log into memory for speed and intermittently flush this to the database. This setup would have to allow for multiple instances too so I would suggest that when it flushed it simple adds its count onto the one stored in the database and then resets the memory count back to 0.
Triggers for a flush could be:
- if the counter gets above a threshold (so if the counter gets up to 1,000 then flush)
- if its been more than X minutes since we flushed (and the counter is not zero)
- on shut down events?
The amounts should be configurable of course with some sensible defaults baked in. Suggest that is stored in a config file.
These counts can get HUGE so we would need to use a suitably large int for them. I'd suggest we store a last accessed time too so we can see when that field was last hit.
This mod wouldn't tell you if anyone is using the field elsewhere (and to be fair this mod might make a nice Core change or a separate package at some point) but it will give you eyes on the usage for the sake of GraphQL.
A report for the back office might be nice but first step is getting something logged to the database.