[1/3 (probably)]: A typical batch compiler may have the following high level architecture: - read all the files - parse all the files - validate everything - generate all the artifacts If any stage fails, we throw away everything, and the next time we run it, we start from scratch and don't reuse any saved state. This has the advantage of being very simple to write and easy to reason about. An incremental compiler (i.e. one in watch mode) tries to reuse as much as it can. That's not very useful if our compiler is structured as above, since the first step involves all the files, so any change will invalidate the results of the first step, invalidating everything afterward. Womp womp. We effectively can't actually reuse any values. So, instead, we might refactor it to something like: - for each file - read, parse - validate everything - generate all the artifacts Now we're getting somewhere! You modify one file, you can at least reuse the parsed AST for every unchanged file. The "validate everything" step is still redone on every compilation, though, and it's probably the expensive part. An even better architecture (EBA) would try to push the "validate everything" as far back as possible, e.g. structuring it more like: - for each artifact we need to generate: - validate what we need, meaning we - parse and read what we need Now, with this architecture, we can reuse even more intermediate results. But now we have a problem: how do we know what we can reuse and what we can't? If the file containing `extend type User { name: String }` is changed, does a fragment on Query need to be revalidated? Maybe! It depends, does it access User and does it access name? What we really don't want to do is try to manually track that invalidation! That's error prone to begin with, and hard to maintain as we iterate on the compiler.