3 ms·

Basically you would have to prove that your rewrites are confluent in the sense of a term-rewriting system[1]. I'm not sure if the project here gives you any he

Basically you would have to prove that your rewrites are confluent in the sense of a term-rewriting system[1]. I'm not sure if the project here gives you any help in doing that, but it would be pretty cool if you could somehow prove the rewrites are confluent. [1]https://en.wikipedia.org/wiki/Confluence_(abstract_rewriting) https://en.wikipedia.org/wiki/Confluence_(abstract_rewriting...

setr 7y ago
That only half-helps though doesn’t it? It saves you from rewrite-order dependence, but doesn’t the requirement that one has to follow ten rewrite (patches?) to figure out what was actually expressed by a query in the codebase. Which takes it down from hell-mode to hard-mode difficulty
- anaphor 7y ago
  Yeah that's true, and now that you mention it, maybe patch theory could help (in the sense of Pijul, Darcs, etc) Though I don't know how much effort I would spend on trying to make this work.
  - setr 7y ago
    The problem I think is that at least with patching, its a run-once situation; once its updated, you never have to see that code/binary again. With query rewriting, its a continual patch, which applies both against the old queries.., and when the old queries are modified; that is, two divergent codebases now exist, referring to different schemas, but unknowingly one codebase gets warped into a different universe where its query somehow works. Both codebases continue to exist, and continue to be worked on. Divergent, yet somehow converging. Every client hit by query rewriting is another divergence. The issue is that the codebase’s query in fact needs to be rewritten.. once, and finally! If you only modify it in-stream... then the rewrite rule must exist until the end of time, or the codebase is updated manually. So really you want a way to patch codebases you probably don’t control.. but I think if you can solve that, you’ve solved APIs everywhere
    - anaphor 7y ago
      So maybe what's really needed is an editor plugin for GraphQL that lets you auto-rewrite queries, or if the queries are generated by a library, then that library should do it.
      - setr 7y ago
        The thing though is that you don’t actually want to rewrite at runtime; thats the hacky solution which ends up as layers of rewrites. You want to rewrite at compile-time, rewriting the codebase itself, and save the changes to version control. As if a human were updating to a new schema. You don’t want to allow stale, unversioned schema-references littered around the codebase itself; being valid by the time it executes is fine and well functionally, but hell to follow

setr 7y ago

That only half-helps though doesn’t it? It saves you from rewrite-order dependence, but doesn’t the requirement that one has to follow ten rewrite (patches?) to figure out what was actually expressed by a query in the codebase. Which takes it down from hell-mode to hard-mode difficulty

anaphor 7y ago
Yeah that's true, and now that you mention it, maybe patch theory could help (in the sense of Pijul, Darcs, etc) Though I don't know how much effort I would spend on trying to make this work.
- setr 7y ago
  The problem I think is that at least with patching, its a run-once situation; once its updated, you never have to see that code/binary again. With query rewriting, its a continual patch, which applies both against the old queries.., and when the old queries are modified; that is, two divergent codebases now exist, referring to different schemas, but unknowingly one codebase gets warped into a different universe where its query somehow works. Both codebases continue to exist, and continue to be worked on. Divergent, yet somehow converging. Every client hit by query rewriting is another divergence. The issue is that the codebase’s query in fact needs to be rewritten.. once, and finally! If you only modify it in-stream... then the rewrite rule must exist until the end of time, or the codebase is updated manually. So really you want a way to patch codebases you probably don’t control.. but I think if you can solve that, you’ve solved APIs everywhere
  - anaphor 7y ago
    So maybe what's really needed is an editor plugin for GraphQL that lets you auto-rewrite queries, or if the queries are generated by a library, then that library should do it.
    - setr 7y ago
      The thing though is that you don’t actually want to rewrite at runtime; thats the hacky solution which ends up as layers of rewrites. You want to rewrite at compile-time, rewriting the codebase itself, and save the changes to version control. As if a human were updating to a new schema. You don’t want to allow stale, unversioned schema-references littered around the codebase itself; being valid by the time it executes is fine and well functionally, but hell to follow