Avoid abusing response::MapType

[barbieri]

Currently to cope with a single resolve() interface that returns a MapType, we're creating too many of them in intermediate steps only to hold data and errors keys.

See https://github.com/microsoft/cppgraphqlgen/blob/master/src/GraphQLService.cpp#L1271-L1297 and the related code.

I tried to convert to a ResolveResult struct with only 2 optionals: data and errors. This would save lots of memory pressure, allow simple lookups and all. But it was very cumbersome, it would require some changes to the generators and I did abort the patch (but it's partially saved, if you think it's the way to go I can resume work on that).

Another approach that I though is to add another response::ResultType that is compatible with map (would change the internals of GraphQLResponse.cpp to handle the new type), the internal usages would go with the new type, such as a new getData() and getErrors() that works only on ResultType. For externals (like the user application resolve()), once get<MapType>() or release<MapType>() it could create an internal map on demand (for get, release just returns it). This would be more "backwards compatible".

Do you think this may work? If so I can work on another PR.

[wravery]

I like the idea of creating a separate ResultType, that seems like it would simplify a lot of the aggregation and bubbling up of errors from nested objects. Rather than converting the errors to a List Value, it could also keep a more strongly typed std::vector<service::schema_error>, but then service::schema_error should become a general purpose response::Error struct.

[barbieri]

I'll see when I can work on this, likely by next week.

[barbieri]

#126 now includes the ResultType

[barbieri]

thanks for fixing this one :-)