Implement requestless connectors using mappingOnly @connect attribute

[andrewmcgivery]

This PR updated @connect to accept a mappingOnly property which can be used for a "requestless connector", meaning a connector that applies a mapping but does not send an http request.

The @connect directive now must have one of mappingOnly or http, but not both. This is handled in validation code.

This also works with nested mutations:

---

Checklist

Complete the checklist (and note appropriate exceptions) before the PR is marked ready-for-review.

• PR description explains the motivation for the change and relevant context for reviewing
• PR description links appropriate GitHub/Jira tickets (creating when necessary)
• Changeset is included for user-facing changes
• Changes are compatible¹
• Documentation² completed
• Performance impact assessed and acceptable
• Metrics and logs are added³ and documented
• Tests added and passing⁴
  • Unit tests
  • Integration tests
  • Manual tests, as necessary

Exceptions

Note any exceptions here

Notes

Footnotes

1. It may be appropriate to bring upcoming changes to the attention of other (impacted) groups. Please endeavour to do this before seeking PR approval. The mechanism for doing this will vary considerably, so use your judgement as to how and when to do this. ↩

2. Configuration is an important part of many changes. Where applicable please try to document configuration examples. ↩

3. A lot of (if not most) features benefit from built-in observability and debug-level logs. Please read this guidance on metrics best-practices. ↩

4. Tick whichever testing boxes are applicable. If you are adding Manual Tests, please document the manual testing (extensively) in the Exceptions. ↩

[apollo-librarian]

✅ Docs preview has no changes

The preview was not built because there were no changes.

Build ID: 4e9aa07837716ce6a74e9453
Build Logs: View logs

---

✅ AI Style Review — No Changes Detected

No MDX files were changed in this pull request.

Review Log: View detailed log

This review is AI-generated. Please use common sense when accepting these suggestions, as they may not always be accurate or appropriate for your specific context.

[github-actions]

@andrewmcgivery, please consider creating a changeset entry in /.changesets/. These instructions describe the process and tooling.

[benjamn]

Why do we need mappingOnly: true? Why not just omit the http to indicate you don't want a request?

I imagine @lennyburdette still has useful context here.

[andrewmcgivery]

Why do we need mappingOnly: true? Why not just omit the http to indicate you don't want a request?

I imagine @lennyburdette still has useful context here.

My thought process was that we may want it to be explicit for two reasons...

First, because I could imagine a future with other types of connectors that also don't use the http attribute.

E.g.

@connect(sql: {...})

So it won't just be the absence of http, but potentially other attributes.

Second, this way the user could never "accidentally" include or exclude the http attribute and we can give very clear and explicit messages about not being able to use both attributes or an error when neither is included.

---

That all said, Lenny's original design did do what you're suggesting (no extra attribute, lack of http implies requestless), so if we feel strongly about this, I'm willing to remove the attribute and change the logic to "if not http, treat as requestless".

[benjamn]

There's a much better and more accurate way to determine if the developer needs http (or sql or whever else we add): check whether the selection attempts to use data that isn't available in the absence of http, like the $root variable. If it doesn't, then a missing http is totally fine, and the developer has met all the requirements to use the feature.

Asking the developer to throw in mappingOnly: true just makes it their fault if they use something in the selection that isn't allowed, whereas we could be giving them exactly the error they need without asking them to assert confidence with an extra parameter. I'm skeptical of the value mappingOnly provides, as simply analyzing the selection would prevent all the mistakes you're talking about.

If you're really attached to this idea, I would recommend running it by customers so you can be sure this is actually helpful and solves real problems!