Message of the day:
Anything GraphQL and SilverStripe related.
likes GraphQL. The same API, but not the hassle of REST or SOAP
I'm not really intimate with how the schema generation works… but I guess the heavy lifting is to assemble all the fields, right? It wouldn't be possible to assemble the fields, hash them and compare the hash to the previous hash from the cache?
Yeah the problem is that we can’t 100% determine when a flush is needed (technically it’s when you change a single line of PHP or YAML), so I think we’ve got three options: Option A: Force devs to explicitly create/flush cache through separate endpoint Option B: Create an imperfect cache invalidation check in dev/build which works about 95% of the time, but doesn’t work if you define types and fields through PHP rather than YAML. It means any change to YAML (regardless if it’s related to GraphQL) could add ~30s to your dev/build. Rely on devs to remember the edge cases when they need to flush explicitly Option C: Always invalidate GraphQL caches in dev/build, which will add ~30s to your dev/build every time
Those ~30s figures are relative to the size of your schema, but in the end every DataObject managed through the CMS needs a GraphQL type in order to work in an API-driven CMS UI, even if you’re not using GraphQL for your own application.
If the system can automatically detect changes that would require a cache rebuild, then it could also happen upon
dev/build imho. But the +60 Seconds of build-time will raise a plethora of other issues… mainly ones around php execution time