I may be overthinking it, but are controllers and resolvers the same thing in web applications? Coming from the MERN stack, everyone used to call these request processing functions "controllers," but in PERN+GQL, everyone calls them "resolvers." By my understanding, they are the same thing.
Controller/Resolver: A function used to process requests and produce a response in applications?
Disclaimer: this is based on what I've read, not on direct personal experience with GraphQL.
It looks like the term "resolver" is associated with GraphQL (at least in the context of your question), where it has to do with resolving the specification represented by the query into an actual data structure (it figures out how to make the data have a concrete shape, and fill it with values). That is, for each field specified in the query, there's a function that figures out how to resolve that specific field. Each field-specific function is termed a resolver. And then there's some mechanism that calls the corresponding resolvers recursively for each field, until you hit simple (non-composite, scalar) values.
"Each field on each type is backed by a function called the resolver which is provided by the GraphQL server developer. When a field is executed, the corresponding resolver is called to produce the next value.
If a field produces a scalar value like a string or number, then the execution completes. However if a field produces an object value then the query will contain another selection of fields which apply to that object. This continues until scalar values are reached. GraphQL queries always end at scalar values." (source)
So, resolvers are not specifically concerned with handling the web request itself, they have a more narrowly defined job.
In a web app, or a web service, a controller is (more or less) an entry point for a request. A controller can (and often does) call other stuff to handle the details of the request. That is, it orchestrates other objects and functions that have narrower responsibilities, and that collaborate together to fulfill the request. That's just the normal responsibility segregation (i.e. as soon as your logic becomes nontrivial, you don't want to write all of it in the same function on the controller).
With GraphQL (or any query-based approach), you can replace all endpoints that allow callers to request data in a predefined way (or some subset of such endpoints), with a single endpoint that accepts a user-provided query, which allows them to specify exactly what they want. The query itself plays the same role that URL parameters or request body did in a traditional Web APIs (the query is a form of input), it's just that's it's more powerful, because it's a language of sorts.
So, with a query-based approach, you can have a single entry point - a single controller - that, among other things, calls some resolver to ask it to interpret/resolve the query (or a part of it) into an actual data structure. Maybe it orchestrates which resolver is called when, or how the data is combined into the final result (not sure about the details in the GraphQL case). You could in principle do extra stuff before and/or after you call the resolver(s) (like authorization, query extraction/parsing, or field censoring, or something), and then return the response to the client. And you could implement all this manually.
I'm guessing that in various frameworks that have support for GraphQL, the presence of the controller (or whatever internal system takes on its role) and other supporting systems is not obvious (as in, the framework might handle all the controller-y details for you, and call the resolver(s) for you) - so I'm guessing that this is the source of your confusion.
So, to summarize: to me, it looks like the conceptual responsibility of the resolver isn't to respond to the request, but to figure out how to transform the data, as it exist in some storage or data source, into the user-specified shape (the data format that the user wants). When you think about it, you could have a similar concept without having a client/server architecture (you could have a scenario where you query your own local data, without going over the web, so the concept itself is not fundamentally web-related).
