[Discussion] Spatial data with hc

[John0x]

Summary

Hey, as discussed before on slack with @PascalSenn and @michaelstaib, I'm kinda struggling with GeoJSON and hc right now.

My current project has to work with a lot of geo data, therefore I want it to be as comfortable as possible. The Geo data is stored in a PostgreSQL database using Postgis. For the interaction between my api and the database I'm using ef core with npgsql. They recommend using the NetTopologySuite to work with spatial data, see:
https://www.npgsql.org/efcore/mapping/nts.html

NetTopologySuite has a base type, called Geometry. It also has more specific types like Point and LineString which extend the Geometry class. The current standard for geo data transportation seems to be GeoJSON, which seems to work pretty well with NetTopologySuite. There even is an existing Json transformer for transforming between NetTopologySuite and GeoJSON: https://github.com/NetTopologySuite/NetTopologySuite.IO.GeoJSON

What's the best way to work with data like that using hc?
I tried different solutions (see attempts down below) and feel kinda stuck right now.

Slack discussion:

• https://hotchocolategraphql.slack.com/archives/CD9TNKT8T/p1585903617176000

Related issues:

• Configuration of AnyType #1303
• Custom scalar for JObject is not parsed correctly #1051

Attempt 1: Custom Scalar

Having read about the scalar implementation with hc from the docs I wanted to try that first.

I want to use the NetTopologySuite types like it's something that hc can handle. Being able to just have a Point for an argument type is quite nice. Something like this:

    [ExtendObjectType(Name = "Query")]
    public class PointQuery
    {
        public Point Hello(Point startPoint)
        {
            // do something with startPoint
            var p = new Point(startPoint.x, startPoint.y);
            
            // return a Point instance
            return p;
        }
    }

Scalars can be problematic for the tooling, as pointed out by @PascalSenn on slack, but they seem to be the most comfortable to use, since I can just bind them to the Point class (.BindClrType<Point, GeoScalar>()).

My implementation: https://github.com/John0x/hotchocolate-geojson-test
It's using the aforementioned JsonTransformer but it feels really hacky :/

The input works but I cannot output a json structure. I could probably just return it as a string, but that feels way too hacky.

Attempt 2: Input and output objects and manual conversion

It would be nice to use GeoJSON, since it's used by a lot of people but it's also okayish to not use it, if it's too inconvenient for GraphQL. The idea for this one would be to have properly typed input and output objects for each specific spatial type (like Point and LineString) and then do the conversion manually using extension methods or something else.
Like this:

    [ExtendObjectType(Name = "Query")]
    public class PointQuery
    {
        public Point Hello(PointInput startPoint)
        {
            // convert to real Point
            var pAsPoint = startPoint.toPoint();
            
            var p = new Point(pAsPoint.x, pAsPoint.y);
            
            // convert to PointOutput
            return p.toOutput();
        }
    }

This would probably work just fine and be the cleanest from the perspective of someone consuming the API, but it's more overhead for the development team.

Conclusion

I'm not sure 😄
It would be nice to have a mix between attempt 1 and 2. Being able to use BindClrType to bind something like a DTO to a CLR Type, which takes care of the conversion between the GraphQL representation and the real class.

Or is there already something like that and I just didn't see it?

[John0x]

Is there no proper solution to this right now or why did it get the HC-11.x.x tag? :)

[michaelstaib]

The tag is just backlog tag. HC-11.0.0 => current work backlog, HC => HC-11.x.x => later

[steveoh]

https://hasura.io/docs/1.0/graphql/manual/queries/query-filters.html#postgis-spatial-relationship-operators-st-contains-st-crosses-etc looks like a nice implementation with postgis

[michaelstaib]

@John0x we have opened a discussion on slack #spatial

[michaelstaib]

#1747

[John0x]

closing in favor of: #1878