Tweak headers to make compilation faster

[barbieri]

Hi @wravery, it's me again :-) In order to avoid large PR being dropped, I'm opening this issue to get your feeling:

Currently the separate will use a single huge header full of templates that makes the compilation of large schemas painful slow. Example:

• https://github.com/microsoft/cppgraphqlgen/blob/main/samples/separate/AppointmentConnectionObject.cpp
• includes https://github.com/microsoft/cppgraphqlgen/blob/main/samples/separate/TodayObjects.h
• includes all objects, ex: https://github.com/microsoft/cppgraphqlgen/blob/main/samples/separate/QueryObject.h of which will declare all methods and all.

but most (all?) of them are not needed. AppointmentConnection, for instance, uses https://github.com/microsoft/cppgraphqlgen/blob/main/samples/separate/AppointmentEdgeObject.h but it seems the AppointmentEdge is handled as shared pointer and no direct member access is done.

I didn't try to change any files yet, but I wonder if we could avoid such full types and replace them with forward declarations whenever possible.

Also, as we're a generator and we know the dependencies, we could emit just the forward declarations for the types used in that file, reducing the compilation time.

[wravery]

Sounds promising. To start with we could replace the ...Objects.h include with a block of forward declarations for every object, or generate a new header with just the forward declarations and use that in the generated ...Obiect.cpp files. Consumers may still depend on the ...Objects.h header as a convenience header, so we should still generate it as is, but we don't need to use it internally. Actually, I think the ...Schema.h file has a block of forward declarations at the top already, at least in the unified schema, so it should be pretty easy to re-target that at another header or unblock injecting it there as the more targeted shared header.

Doing dependency analysis to limit the set of includes may not be worth the added complexity, unless it turns out the forward declarations don't work by themselves and there's a dependency on the full class definitions in the generated code. In that case, dependency analysis could determine a more scoped set of includes to use.

[barbieri]

ok, I guess the forward declarations should do (no need to see which one we should do based on the file usage). we'll take a look.

[wravery]

Oops, hit the wrong button in the mobile app. Didn't mean to close it.

[wravery]

I thought C++20 Modules would solve this, but I need to postpone adopting that since it's not supported by CMake yet. I'll revisit this separately.

[barbieri]

Nice, let us know! FYI, the project we worked on is now public, but we're finished adding more details for the time being, it was a research project to expose Vehicle Signal Specification (VSS) as GraphQL: https://github.com/COVESA/graphql-vss-server-libs (COVESA was previously known as GENIVI, it's the "connected vehicle systems alliance").

In that repo you can find graphql_vss_server_libs/protocol with some base we use, it does auth using JWT, handles queries and mutations from HTTP and query/mutation/subscriptions using WebSockets, the subscriptions use a non-standard (for GraphQL) single root element (atm we have a single vehicle), so the "matchers" based on root element + arguments was not enough and we had to do some queueing and batch delivery GraphQLServer. It also required us to copy SubscriptionDefinitionNameVisitor so we could access it. All in all it was a great experiment, we have the code generators at https://github.com/COVESA/vss2graphql_schema

Thanks for your work and support :-)