Tweak blog post for Grafast audience

Author: benjie

Diff for: grafast/website/news/2025-03-24-grafast-0.1-beta.21.mdx

@@ -26,10 +26,9 @@ this release, 3 of these are now complete!
 - ✅🎉 **Eradicating eval - this release!**
 - 🤔🔜 Polymorphism
 
-After 3 months of gruelling work, we’re proud to announce that the third of
-these, eradicating eval, is now addressed with the launch of
-`[email protected]` (used as the core execution engine in
-`[email protected]`).
+We’re proud to announce that the third of these, eradicating eval, is now
+addressed with the launch of `[email protected]`, and the approach has been
+fully adopted and tested via incorporation into `[email protected]`.
 
 </p>
 
@@ -38,7 +37,7 @@ these, eradicating eval, is now addressed with the launch of
 Since the beginning, Gra*fast* has had the ability to add plan resolvers not
 just to fields, not just to arguments, but also to input object fields
 (including those within lists). This made Gra*fast*’s planning really ergonomic
-for things like nested filters, which was great for PostGraphile! But it turns
+for things like nested filters. But it turns
 out it’s really problematic for certain shapes of input — planning would put
 constraints on the variables compatible with the plan, requiring potentially
 unlimited numbers of operation plans needing to be built for the same GraphQL
@@ -48,10 +47,10 @@ excessive time.
 
 One particular user example that could cause 4 minutes of planning time from
 just a 100kB input made it clear that we had overreached with using plan
-resolvers too deep into inputs; so we’ve scaled it back so that you can only add
-plan resolvers to fields and arguments, you can no longer attach `applyPlan` or
-`inputPlan` to input object fields. This was something that we used a lot
-internally (hence the huge time investment migrating away!), but very few people
+resolvers too deep into inputs; so we’ve scaled it back so that you can only
+add plan resolvers to fields and arguments, you can no longer attach
+`applyPlan` or `inputPlan` to input object fields. This was something that we
+used a lot in PostGraphile and its various plugins, but very few people
 (no-one?) used externally so it was ripe for removal.
 
 That problematic query that took 4 minutes to plan before? It now takes 1.1ms to
@@ -61,22 +60,23 @@ plan, yielding a 200,000x speedup!
 
 ### What does this mean for my codebase?
 
-Hopefully good things! Please update to the latest `@beta` of all the
-PostGraphile and/or Gra*fast* related modules you’re using (including plugins)
-and for most users everything should work as before, only better.
+Hopefully good things! Please update to the latest `grafast@beta` and for most
+users everything should work as before, only better.
 
-I’ve outlined some of the most common changes you may need to make below, but if
-you are impacted by any other changes, please ask for help in the chat — AFAIK
-most of the other things that have had significant changes are used by almost
-no-one except me, so it doesn’t make sense for me to invest time documenting it
-here. If you’re curious, many items are documented in both the changelogs and
+I’ve outlined some of the most common changes you may need to make below, but
+if you are impacted by any other changes, please ask for help [in the
+chat](https://discord.gg/graphile) — AFAIK most of the other things that have
+had significant changes are used by almost no-one except me, so it doesn’t make
+sense for me to invest time documenting it here since the software is still in
+beta. If you’re curious, many items are documented in both the changelogs and
 the pull requests where the changes occurred.
 
 #### Change `fieldArgs.get` to `fieldArgs.getRaw`
 
 Because we’ve removed `inputPlan`, the `fieldArgs.get(key)` method is no more;
 instead use `fieldArgs.getRaw(key)` which is equivalent unless the inputs had
-plans (which they cannot any more).
+plans (which they cannot any more). You'd know if you had plans on your inputs,
+it's very unlikely you did if you were writing your own Gra*fast* schema.
 
 #### Converting `applyPlan` and `inputPlan`
 
@@ -87,13 +87,13 @@ runtime application or transform of these inputs recursively via a single step
 in our plan diagram.
 
 We’ve managed to make this new runtime system very similar in shape to the old
-plan-time system, so PostGraphile plugins don’t need to change much — this was
-largely enabled by how closely we managed to get the Gra*fast* plan syntax to the
-syntax of code you would normally write at runtime. The first change is to
-rename `applyPlan` to `apply`, and `inputPlan` to `baked`. From there, your code
-might just work straight away, or it might need some more small tweaks (e.g.
-`fieldArgs` is no longer present, it’s been replaced with simply the runtime
-value of the current field).
+plan-time system (largely enabled by how closely we managed to get the
+Gra*fast* plan syntax to the syntax of code you would normally write at
+runtime), so if you do need to transform any it shouldn't take much effort. The
+first change is to rename `applyPlan` to `apply`, and `inputPlan` to `baked`.
+From there, your code might just work straight away, or it might need some more
+small tweaks (e.g. `fieldArgs` is no longer present, it’s been replaced with
+simply the runtime value of the current field).
 
 #### No more `$step.eval*()`
 
@@ -102,6 +102,11 @@ you try and use them. They will likely be removed at some point after release,
 so you should be sure to migrate away from using them at your earliest
 opportunity. But you weren’t using them anyway… right?
 
+If you were, a new `.apply()` pattern has been added to various steps to enable
+you to specify runtime tweaks the step can apply as its executing, for example
+changing the `ORDER BY` clause in an SQL query based on a variable argument.
+You may want to adopt a similar pattern in your own step classes.
+
 #### ExecutableStep renamed to Step
 
 This one is more cosmetic…