question/maybe feature: support for functional controller definitions

[xenoterracide]

Does spring graphql support this feature?

https://docs.spring.io/spring-framework/reference/web/webmvc-functional.html
https://docs.spring.io/spring-framework/reference/web/webflux-functional.html

google AI gave me this example (so if it doesn't work...)

@Configuration
public class RouterConfig {

    @Bean
    public RouterFunction<ServerResponse> userRoutes() {
        return route(GET("/hello"), 
                request -> ServerResponse.ok().body("Hello, Lambda!"))
            .and(route(GET("/greet/{name}"), 
                request -> {
                    String name = request.pathVariable("name");
                    return ServerResponse.ok().body("Greetings, " + name + "!");
                })
            );
    }
}

and my thought is it might be a reasonably good solution to #1144

[bclozel]

I think you're conflating what Spring MVC and Spring GraphQL do. They both provide an annotation programming model but the infrastructure and behavior behind that are quite different. Spring MVC abstracts the Servlet API and adds concepts like content negotiation, application routes, etc.

Here Spring GraphQL promotes existing graphql-java concepts to a well-known programming model. There is no need to write a new functional model as it's already provided by graphql-java itself. If you want to write data fetchers in a functional way, you can already do so with the graphql-java API.

Here's an example of how to contribute a data fetcher with Spring Boot:

@Configuration
public class GraphQlConfiguration {

	@Bean
	public RuntimeWiringConfigurer runtimeWiringConfigurer() {
		DataFetcher<Author> authorDataFetcher = //...
		return wiring -> {
			wiring.type("Book", type -> type.dataFetcher("author", authorDataFetcher));
			//...
		};
	}
}

[xenoterracide]

That's a data fetcher, how would I do route(GET (...))

The only way I see to do that is annotation-based controllers. As I would think the equivalent would be route(QUERY(...))

It's the DSL for routing that I don't see that I think is missing.

[bclozel]

There is no concept of route in GraphQL, it is transport agnostic.
We already use the functional web APIs to plug the HTTP transport into our GraphQL engine.

I guess I don't understand what you are trying to achieve.

[xenoterracide]

right, exactly, but this is the kind of code I'm trying to write (although graphql over http has a minor concept of route... where the /graphql endpoint lives, that doesn't matter to me here).

I'm looking to write controllers in at least a similar DSL-y fashion. I wouldn't care if it was query("...", request -> ... ) or something like that. I was just hoping to get out from under a full class... debatably route is a router meaning route to controller function... which could also be controller agnostic. I've no idea how this works under the hood of spring mvc though and if the router could be used to facilitate the same way @Controller is, although I think this API is meant to server a similar purpose as reflectively looking for @Controller -> method.

basically HTTP has nothing to do with routing either, routing is just about which code to actually call. The general concept of a router is protocol agnostic.

[xenoterracide]

p.s. if you don't have a router how are you figuring out what controller/method to dispatch to? I'm thinking about it, the function is often called a resolver (instead of controller) in graphql land; and the graphql-java library provides access to them, but that's super raw, also not certain how I would safely use that raw-er code.

[rstoyanchev]

Routing for HTTP is finding a match for the URL path.

In GraphQL there is no routing or matching. It is parse the query, navigate the selection set, and invoke the code registered for each field, or find a matching property on the parent Object. This the job of the GraphQL Java engine, and aside from providing a way to register code for fields (i.e. the RuntimeWiring) there isn't much else to do.

[bclozel]

I guess another way to put it is: if we were to work on such a DSL, I think there would be little difference with registering data fetchers. The "equivalent" of the HTTP request would be the DataFetchingEnvironment and the return type Object.

Working on Spring for GraphQL makes us more familiar with the graphql-java API and its concepts. Maybe there is value in providing such a DSL but it's not clear at the moment. To make progress on this, we would need to better understand the use cases where the annotation-model is a limitation, or some more concrete design proposal showcasing a DSL vs. the graphql-java experience.

[xenoterracide]

Yeah, after working on this for the last few weeks (whilst also fighting with corporate code) the RuntimeWiring feature feels like the best option for this.

I think that it might be beneficial to have something done where it would be easy to mutate for an assertion by assertion bases. Since the goal here is to test the client, not the server implementation. I'm not certain how this'll be achieved without just having a seperate test class for each test case where I need a new stack of more or less static data.