Pre-Supergraph Router service layer (HTTP)

[SimonSapin]

Currently we provide:

• A full server that listens for a network requests of various kinds, typically for production use
• A Tower Service for handling GraphQL requests with high-level request and response objects, typically for use in tests

It would make sense to provide the intermediate abstraction of Tower service at the HTTP level, where request and response bodies are raw bytes. This could potentially be run in a different HTTP server.

For 1.0 we want to at least have the separation internally, though perhaps not yet provide a public API for it.

[SimonSapin]

Removing the api/1.0 label now that #1582 ensures that the abstraction can exist. Leaving this issue open so we can decide later if we want a public API to construct this transport-level Service. (Likely with a builder similar to TestHarness.)

[abernix]

As some examples of user-land things which we could enable by supporting this, both of the following use-cases come to mind — though I have closed those issues as "working as intended" in for the common Router user story:

• axum refuses the text/plain content type #1298
  This requests a way to accept different content types, like text/plain. I'm not entirely sure what a text/plain GraphQL query would be (and it would go against work that the GraphQL HTTP working group is trying to specify about how GraphQL should speak HTTP) but it would be good to enable users to make such exceptions if need be, most likely to preserve existing behaviors where necessary.
• can't parse variables from a string #1314
  This suggests allowing a different serialization format for incoming variables and a transport-level service might enable them to coerce that data into a valid GraphQL variables structure.

[lennyburdette]

The most pressing customer use case I have is supporting a custom persisted query implementation. They have old mobile clients sending a weird PQ format and it will take a long time for those version to die off. They handled this in express middleware when using Apollo Gateway.

[SimonSapin]

This is relevant:

router/apollo-router/src/router.rs

Lines 53 to 62 in 538a069

	// For now this is unused:
	#[allow(unused)]
	// Later we might add a public API for this (probably a builder similar to `test_harness.rs`),
	// see https://github.com/apollographql/router/issues/1496.
	// In the meantime keeping this function helps make sure it still compiles.
	async fn make_transport_service<RF>(
	schema: &str,
	configuration: Arc<Configuration>,
	extra_plugins: Vec<(String, Box<dyn DynPlugin>)>,
	) -> Result<transport::BoxCloneService, BoxError> {

An open question that remains is how (and whether?) to expose multiple TCP/Unix listeners

[Geal]

An open question that remains is how (and whether?) to expose multiple TCP/Unix listeners
that would not affect HTTP service plugins, right?

[SimonSapin]

If something like the Prometheus endpoint is configured on a secondary TCP port, should HTTP-level plugins run for those requests as well? Should they be responsible for always checking some property of the request to dispatch on port number as well as URL path?

[o0Ignition0o]

Do yall have opinions on where the http_service should kick in (as in before or after axum routing?)

My opinion is that it should be right after axum routing (The http service stack should only apply to the graphql path) and before anything else happens (headers parsing || studio redirection or body deserialization shouldn't have happened before)

I've also read mentions of the http_service applying before the axum router, I would be interested to read thoughts on that, especially since we now have custom endpoints that could satisfy that.

[bnjjj]

I think having it just after the axum routing makes sense. It should take a raw http request (without json deserialization) and return a raw http response I think