9 ms·

SwiftGraphQL – A GraphQL client that lets you forget about GraphQL

97 points by maticzav 6y ago

msoad 6y ago
Wouldn't it be better to generate those structs from API schema?
- yeneek 6y ago
  I have the same opinion. The big problem I had with generating graphql api from code, was that the result graphql schema was badly done. It's hard to design API that way. I made similar module for typescript just to realize, that I don't want to build graphql endpoints this way. that module: https://github.com/captain-refactor/graphql-compose-typescript https://github.com/captain-refactor/graphql-compose-typescri...
- harryf 6y ago
  You mean something like https://github.com/banjun/WSDL2Swift https://github.com/banjun/WSDL2Swift ?
- maticzav 6y ago
  SwiftGraphQL also generates API structs from the schema. Maybe you are referring to generating the model from the queries. The problem we had with that approach was that it's hard to reuse the generated structures in your application model. You can read more about the idea here: https://github.com/maticzav/swift-graphql#what-are-the-pitfalls-in-apollo-ios-that-you-were-referring-to-at-the-top https://github.com/maticzav/swift-graphql#what-are-the-pitfa...
jtdev 6y ago
Can we just forget about GraphQL completely instead?
- blacktriangle 6y ago
  I have, but I also don't work in an organization that has separate and large front-end and back-end teams. GraphQL looks less like an objectively useful technology and more of a realization of Conway's Law in response to Facebook's organization.
  - RyanShook 6y ago
    Great point. GraphQL looks like overkill for small projects but at the right size it probably makes perfect sense.
    - arcturus17 6y ago
      "Conway's law is an adage stating that organizations design systems which mirror their own communication structure" So if GP is correct and we take them literally then you shouldn't only have the right size, but also a structure that's close to Facebook's...
  - jaegerpicker 6y ago
    As a Mobile Dev/Frontend Dev GraphQL is a massive win to work with. No more requesting/building end points to satisfy the screen you are building. Adding fields is non-destructive. Controlling the shape of the data returned (to an extent, you still have to return it in the nested layers the schema is designed towards). I know a ton of backend or full stack devs that don't think that GraphQL is worth it but very FEW UI devs that agree. It's really nice to build UI's against. I've tried SOAP, REST, HATEOAS, Swagger/OpenAPI, and protobuffers. Protobuffers are the only one with as good a developer experience IMO. GraphQL is OBJECTIVELY useful it might not be useful to you apps though and that's ok.
    - blacktriangle 6y ago
      Objectively was probably the wrong word, maybe "generally" would be more accurate. I was looking to contrast GraphQL with something like REST which is an incredibly powerful generic mental model, where GraphQL seems more specifically tuned to solve front end developer's issues.
- runawaybottle 6y ago
  Oh come on! My company just forced me to learn it for a better part of a year. We can’t be done with it, it’s not fair. I was told this was the new hotness, and I can’t be lied to. Plus, many job descriptions were asking for Graphql about 2 years ago, so what gives? Is life not fair? I was told it was fair this time around.
andrewingram 6y ago
There's also: - Relay-swift: A port of Relay to Swift - https://relay-tools.github.io/Relay.swift/docs/ https://relay-tools.github.io/Relay.swift/docs/ - Graphaello: Inspired by Relay, but deviates a bit more from the patterns than Relay-swift - https://github.com/nerdsupremacist/Graphaello https://github.com/nerdsupremacist/Graphaello
- maticzav 6y ago
  Thank you for adding the links! The main difference between these clients and SwiftGraphQL is that SwiftGraphQL tries to abstract away GraphQL in favour of Swift language feature. `relay-swift`, for example, relies on query strings which doesn't bring type-safety to your code; `graphaello` is indeed very similar and I've tried using it before creating SwiftGraphQL. One of the goals of SwiftGraphQL was to let you easily separate the model from your queries. That's why we let you do complex logic in the selection itself. Otherwise, you'd have to first create a utility struct and then translate it into a model-type. I think that's the main difference between graphaello and SwiftGraphQL Thanks again for sharing the links!
  - ericlewis 6y ago
    Relay.swift doesn't bring type-safety to your queries but it does use the relay-compiler which will fail if anything is wrong (at least helpful!) and you still get type safety for results as well as automatic conformance to Identifiable & custom scalar type substitutions. Haven't checked out SwiftGraphQL much, but Relay.swift is definitely the best swift based GQL I have used to date.
Kaze404 6y ago
I love code generation from GraphQL. Elm-graphql is a great example of this and works incredibly well, to the point where it sold me on GraphQL entirely.
- maticzav 6y ago
  SwiftGraphQL was actually inspired by Elm GraphQL! Dillon - the creator of Elm GraphQL - even helped me understand a couple of concepts he used in that library that we also use in SwiftGraphQL.
j_m_b 6y ago
I wondered when the GraphQL "ORMs" would start appearing!
hardwaresofton 6y ago
Another week, another submission that hopefully edges more people towards realizing that they've just created an under-standardized, under-powered SQL-with-braackets that forces you to bring your own query optimizer, and eschews the advancements of Swagger/OpenAPI, JSONSchema, HAL, JSON-LD and the flexibility of HATEOAS. All for a little bit of a velocity gain from declarative syntax and horizontal/vertical filtering. This code is probably very useful to the people who made it and those in the GraphQL+Swift ecosystem, but we were already here (and just starting to get drastically better) with OpenAPI -- it's not like all the effort is only going in one direction but GraphQL really feels like a less-than-optimal branch. The final piece of the puzzle for me will be when someone starts to replace the dynamic properties of the more advanced REST-ful techniques (API discovery, link following, etc) in GraphQL. Then the circle will be complete -- we'll have rebuilt XML (in the "linked data" respect anyway, not so much the accidental complexity side) and it's related standards twice in under ~20 years.
- rand_r 6y ago
  Does OpenAPI have a way for the client to whitelist fields? I see that as a major selling point for GraphQL. Without it, you end up having to create tailored endpoints for each use-case vs. for example a single “user” endpoint/vertex that supports the complete buffet of fields for all use-cases in one convenient place.
  - hardwaresofton 6y ago
    I can't say that it should have that feature -- I'd say that is outside the purview of OpenAPI itself, but it could definitely be built in in a repeatable and scalable way pretty simply. I can tell you that tools like PostgREST have had this for a long time[0]. [0]: https://postgrest.org/en/v7.0.0/api.html#vertical-filtering-columns https://postgrest.org/en/v7.0.0/api.html#vertical-filtering-...
- mikecaulley 6y ago
  I've found GraphQL to greatly improve the developer experience when building web apps. As a front-end developer you can easily get a full view of the data and relationships. Tools like GraphiQL make exploring APIs a pleasure. And regardless of what you need to present to the user on screen, you can quickly build a request that perfectly matches the data you need. There is also the nice addition of strict typing and there are libraries that automatically generate TypeScript types for you from the schema and/or your operations.
deleted 6y ago
[deleted]
kva 6y ago
I <3 GQL but this just sounds like "Forget the GraphQL DSL to learn our DSL"
pcr910303 6y ago
So a bunch of people on HN are now arguing that GraphQL should disappear? GraphQL is a genuinely objectively useful technology in places that have a frontend-backend split (including non-web frontends). It doesn’t require building specific APIs for specific pages for speed concerns. It allows backends to add fields non-destructively (RESTful JSON does work at the cost of a bigger network payload). GraphQL provides the right tools for the right problem, and has created an ecosystem around it. (How should I reliably compute a SQL query cost? How should I control data access policy in SQL? How should I return the SQL result in a easily-parsable format?)
santialbo 6y ago
I see a lot of hatred in the comments towards GraphQL. Is someone forcing you to use it against your will? I've been using it for more than a year with TypeScript types generation and couldn't be happier. All of my interactions with the server are properly typed and haven't had a single bug related to server/client missmatches.
- serverholic 6y ago
  There are a bunch of elitists on here who get off on hating popular things. I find it amusing that some of the comments are basically "Why use graphql when I can combine these 5 other technologies to do the same thing?"
  - ehutch79 6y ago
    It's not graphql that's the issue. it's another tool. It's the fanboys, and more the people selling tooling. There's a guy who (was?) over at graphqleditor.com that was posting a whole bunch of articles, at least one of one said it was a mistake not to convert all your shit to graphql immediately.
- tylerchilds 6y ago
  > Is someone forcing you to use it against your will? I mean, kind of? My problem with GraphQL isn't necessarily GraphQL itself, but with the sprawl of things creeping further and further into client-side code. As companies are finding GraphQL to "unlock greater developer productivity", it's becoming more and more expected to have this in our toolkit as "front-end people". There's been a few blog posts recently that I relate to. I feel like I'm at a point in my career where I could "knuckle-down and get good" but I don't actually want to get good at more and more endless technologies. I'd rather be able to define my niche specialization and thrive within that space. [1]: https://bradfrost.com/blog/post/front-of-the-front-end-and-back-of-the-front-end-web-development/ https://bradfrost.com/blog/post/front-of-the-front-end-and-b... [2]: https://www.trysmudford.com/blog/i-think-im-a-design-engineer/ https://www.trysmudford.com/blog/i-think-im-a-design-enginee... [3]: https://notes.baldurbjarnason.com/2021/02/20/the-layers-of.html https://notes.baldurbjarnason.com/2021/02/20/the-layers-of.h...
dsabanin 6y ago
What's with the GraphQL luddism on HN? I'm as much opposed to adding more incidental complexity to the frontend as the next guy, but GraphQL has objective purpose and makes a lot of things much simpler than they would be without it. Learning new things and doing things better than they were done a year before is an essential part of being a professional software engineer, it's what makes this field hard and that's why we're paid so much. It's what makes us able to tackle so much added complexity of the world, new use cases, new platforms and paradigm shifts over the years. To me, it's also what makes it so challenging and rewarding.
- ritchiea 6y ago
  It’s dismissive to call it luddism. I am a big anti-GraphQL voice but in the specific cases where I tend to work: on small cross functional, often full stack dev teams. It’s a layer of formal promises about the API that I find extremely unnecessary & unproductive for small teams that I can see the appeal for at a huge corp like Facebook where frontend devs probably don’t write much or any backend code. The problem usually isn’t the library itself and that’s true of GraohQL. It’s the cargo culting of GraphQL & other new tech that might be unnecessary or overengineering for your specific use case.
- dmitriid 6y ago
  > I'm as much opposed to adding more incidental complexity to the frontend as the next guy, but GraphQL has objective purpose and makes a lot of things much simpler By moving all that complexity to the backend. It's not luddism to call this out. > Learning new things and doing things better than they were done a year before is an essential part of being a professional software engineer Yeah, no. It's not "better than they were done a year ago". It's just dumping all the complexity in somebody else's lap, reimplements a bunch of things from scratch, poorly, and calls it progress.
mjmahone17 6y ago
This is really cool! I love seeing GraphQL back in its roots as a way of improving the developer experience for native iOS apps. From what I understand, this project tries to solve one clear pain point that isn't solved elsewhere: Swift developers can use GraphQL in Swift without writing GraphQL directly. Being able to create idiomatic operations through Swift is nifty to see. Somewhat interestingly, it seems like to solve other problems, @maticzav is independently following similar paths that the original developers of GraphQL in Objective-C followed. Some of the highlights: - Using code generation to make access patterns more type safe. - Creating a centralized set of Type Models, that map 1:1 with the schema the app accesses. - Mostly separating the GraphQL operations (in this case, as written in Swift) from the models a component interacts with: the components just see that they have a Schema-based Type Model. I'd personally think about using the query-creation API to produce query (and fragment, once those are supported) specific models for consumption. The problems of both over and under fetching may expose themselves when more than a couple interactions are operating with different views over the same types. I've talked about why Facebook no longer recommends Type Models before: https://www.youtube.com/watch?v=Vo8nqjiKI3A https://www.youtube.com/watch?v=Vo8nqjiKI3A It's really encouraging to see the recent explosion of ideas for "how to do GraphQL": I'm not sure what sort of synthesis these myriad projects will create for the broader community.
adsharma 6y ago
Re: Conways law at Facebook I was at Facebook when GraphQL was invented, maintaining a backend storage service where a core assumption was that storage should be reorganized based on access patterns and that predicates should be pushed down to storage where they can be executed more efficiently. GraphQL was hard to push predicates down, because you don't know which of the edges were written in PHP. My response was fquery[1], which is like what's being discussed here but with python as the source language instead of swift and amenable to preserving the largest possible query structure for backend optimizers, including SQL optimizers. It has some early demos converting a GraphQL/fquery into SQL where possible. It should be possible to add enough metadata to fquery to identify if an edge is non-trivial (calls into another microservice) or trivial (can be optimized to a storage backend or SQL). [1] https://github.com/adsharma/fquery https://github.com/adsharma/fquery

97 points by maticzav 6y ago

msoad 6y ago

Wouldn't it be better to generate those structs from API schema?

yeneek 6y ago
I have the same opinion. The big problem I had with generating graphql api from code, was that the result graphql schema was badly done. It's hard to design API that way. I made similar module for typescript just to realize, that I don't want to build graphql endpoints this way. that module: https://github.com/captain-refactor/graphql-compose-typescript https://github.com/captain-refactor/graphql-compose-typescri...
harryf 6y ago
You mean something like https://github.com/banjun/WSDL2Swift https://github.com/banjun/WSDL2Swift ?
maticzav 6y ago
SwiftGraphQL also generates API structs from the schema. Maybe you are referring to generating the model from the queries. The problem we had with that approach was that it's hard to reuse the generated structures in your application model. You can read more about the idea here: https://github.com/maticzav/swift-graphql#what-are-the-pitfalls-in-apollo-ios-that-you-were-referring-to-at-the-top https://github.com/maticzav/swift-graphql#what-are-the-pitfa...

jtdev 6y ago

Can we just forget about GraphQL completely instead?

blacktriangle 6y ago
I have, but I also don't work in an organization that has separate and large front-end and back-end teams. GraphQL looks less like an objectively useful technology and more of a realization of Conway's Law in response to Facebook's organization.
- RyanShook 6y ago
  Great point. GraphQL looks like overkill for small projects but at the right size it probably makes perfect sense.
  - arcturus17 6y ago
    "Conway's law is an adage stating that organizations design systems which mirror their own communication structure" So if GP is correct and we take them literally then you shouldn't only have the right size, but also a structure that's close to Facebook's...
- jaegerpicker 6y ago
  As a Mobile Dev/Frontend Dev GraphQL is a massive win to work with. No more requesting/building end points to satisfy the screen you are building. Adding fields is non-destructive. Controlling the shape of the data returned (to an extent, you still have to return it in the nested layers the schema is designed towards). I know a ton of backend or full stack devs that don't think that GraphQL is worth it but very FEW UI devs that agree. It's really nice to build UI's against. I've tried SOAP, REST, HATEOAS, Swagger/OpenAPI, and protobuffers. Protobuffers are the only one with as good a developer experience IMO. GraphQL is OBJECTIVELY useful it might not be useful to you apps though and that's ok.
  - blacktriangle 6y ago
    Objectively was probably the wrong word, maybe "generally" would be more accurate. I was looking to contrast GraphQL with something like REST which is an incredibly powerful generic mental model, where GraphQL seems more specifically tuned to solve front end developer's issues.
runawaybottle 6y ago
Oh come on! My company just forced me to learn it for a better part of a year. We can’t be done with it, it’s not fair. I was told this was the new hotness, and I can’t be lied to. Plus, many job descriptions were asking for Graphql about 2 years ago, so what gives? Is life not fair? I was told it was fair this time around.

andrewingram 6y ago

There's also: - Relay-swift: A port of Relay to Swift - https://relay-tools.github.io/Relay.swift/docs/ https://relay-tools.github.io/Relay.swift/docs/ - Graphaello: Inspired by Relay, but deviates a bit more from the patterns than Relay-swift - https://github.com/nerdsupremacist/Graphaello https://github.com/nerdsupremacist/Graphaello

maticzav 6y ago
Thank you for adding the links! The main difference between these clients and SwiftGraphQL is that SwiftGraphQL tries to abstract away GraphQL in favour of Swift language feature. `relay-swift`, for example, relies on query strings which doesn't bring type-safety to your code; `graphaello` is indeed very similar and I've tried using it before creating SwiftGraphQL. One of the goals of SwiftGraphQL was to let you easily separate the model from your queries. That's why we let you do complex logic in the selection itself. Otherwise, you'd have to first create a utility struct and then translate it into a model-type. I think that's the main difference between graphaello and SwiftGraphQL Thanks again for sharing the links!
- ericlewis 6y ago
  Relay.swift doesn't bring type-safety to your queries but it does use the relay-compiler which will fail if anything is wrong (at least helpful!) and you still get type safety for results as well as automatic conformance to Identifiable & custom scalar type substitutions. Haven't checked out SwiftGraphQL much, but Relay.swift is definitely the best swift based GQL I have used to date.

Kaze404 6y ago

I love code generation from GraphQL. Elm-graphql is a great example of this and works incredibly well, to the point where it sold me on GraphQL entirely.

maticzav 6y ago
SwiftGraphQL was actually inspired by Elm GraphQL! Dillon - the creator of Elm GraphQL - even helped me understand a couple of concepts he used in that library that we also use in SwiftGraphQL.

j_m_b 6y ago

I wondered when the GraphQL "ORMs" would start appearing!

hardwaresofton 6y ago

Another week, another submission that hopefully edges more people towards realizing that they've just created an under-standardized, under-powered SQL-with-braackets that forces you to bring your own query optimizer, and eschews the advancements of Swagger/OpenAPI, JSONSchema, HAL, JSON-LD and the flexibility of HATEOAS. All for a little bit of a velocity gain from declarative syntax and horizontal/vertical filtering. This code is probably very useful to the people who made it and those in the GraphQL+Swift ecosystem, but we were already here (and just starting to get drastically better) with OpenAPI -- it's not like all the effort is only going in one direction but GraphQL really feels like a less-than-optimal branch. The final piece of the puzzle for me will be when someone starts to replace the dynamic properties of the more advanced REST-ful techniques (API discovery, link following, etc) in GraphQL. Then the circle will be complete -- we'll have rebuilt XML (in the "linked data" respect anyway, not so much the accidental complexity side) and it's related standards twice in under ~20 years.

rand_r 6y ago
Does OpenAPI have a way for the client to whitelist fields? I see that as a major selling point for GraphQL. Without it, you end up having to create tailored endpoints for each use-case vs. for example a single “user” endpoint/vertex that supports the complete buffet of fields for all use-cases in one convenient place.
- hardwaresofton 6y ago
  I can't say that it should have that feature -- I'd say that is outside the purview of OpenAPI itself, but it could definitely be built in in a repeatable and scalable way pretty simply. I can tell you that tools like PostgREST have had this for a long time[0]. [0]: https://postgrest.org/en/v7.0.0/api.html#vertical-filtering-columns https://postgrest.org/en/v7.0.0/api.html#vertical-filtering-...
mikecaulley 6y ago
I've found GraphQL to greatly improve the developer experience when building web apps. As a front-end developer you can easily get a full view of the data and relationships. Tools like GraphiQL make exploring APIs a pleasure. And regardless of what you need to present to the user on screen, you can quickly build a request that perfectly matches the data you need. There is also the nice addition of strict typing and there are libraries that automatically generate TypeScript types for you from the schema and/or your operations.

deleted 6y ago

[deleted]

kva 6y ago

I <3 GQL but this just sounds like "Forget the GraphQL DSL to learn our DSL"

pcr910303 6y ago

So a bunch of people on HN are now arguing that GraphQL should disappear? GraphQL is a genuinely objectively useful technology in places that have a frontend-backend split (including non-web frontends). It doesn’t require building specific APIs for specific pages for speed concerns. It allows backends to add fields non-destructively (RESTful JSON does work at the cost of a bigger network payload). GraphQL provides the right tools for the right problem, and has created an ecosystem around it. (How should I reliably compute a SQL query cost? How should I control data access policy in SQL? How should I return the SQL result in a easily-parsable format?)

santialbo 6y ago

I see a lot of hatred in the comments towards GraphQL. Is someone forcing you to use it against your will? I've been using it for more than a year with TypeScript types generation and couldn't be happier. All of my interactions with the server are properly typed and haven't had a single bug related to server/client missmatches.

serverholic 6y ago
There are a bunch of elitists on here who get off on hating popular things. I find it amusing that some of the comments are basically "Why use graphql when I can combine these 5 other technologies to do the same thing?"
- ehutch79 6y ago
  It's not graphql that's the issue. it's another tool. It's the fanboys, and more the people selling tooling. There's a guy who (was?) over at graphqleditor.com that was posting a whole bunch of articles, at least one of one said it was a mistake not to convert all your shit to graphql immediately.
tylerchilds 6y ago
> Is someone forcing you to use it against your will? I mean, kind of? My problem with GraphQL isn't necessarily GraphQL itself, but with the sprawl of things creeping further and further into client-side code. As companies are finding GraphQL to "unlock greater developer productivity", it's becoming more and more expected to have this in our toolkit as "front-end people". There's been a few blog posts recently that I relate to. I feel like I'm at a point in my career where I could "knuckle-down and get good" but I don't actually want to get good at more and more endless technologies. I'd rather be able to define my niche specialization and thrive within that space. [1]: https://bradfrost.com/blog/post/front-of-the-front-end-and-back-of-the-front-end-web-development/ https://bradfrost.com/blog/post/front-of-the-front-end-and-b... [2]: https://www.trysmudford.com/blog/i-think-im-a-design-engineer/ https://www.trysmudford.com/blog/i-think-im-a-design-enginee... [3]: https://notes.baldurbjarnason.com/2021/02/20/the-layers-of.html https://notes.baldurbjarnason.com/2021/02/20/the-layers-of.h...

dsabanin 6y ago

What's with the GraphQL luddism on HN? I'm as much opposed to adding more incidental complexity to the frontend as the next guy, but GraphQL has objective purpose and makes a lot of things much simpler than they would be without it. Learning new things and doing things better than they were done a year before is an essential part of being a professional software engineer, it's what makes this field hard and that's why we're paid so much. It's what makes us able to tackle so much added complexity of the world, new use cases, new platforms and paradigm shifts over the years. To me, it's also what makes it so challenging and rewarding.

ritchiea 6y ago
It’s dismissive to call it luddism. I am a big anti-GraphQL voice but in the specific cases where I tend to work: on small cross functional, often full stack dev teams. It’s a layer of formal promises about the API that I find extremely unnecessary & unproductive for small teams that I can see the appeal for at a huge corp like Facebook where frontend devs probably don’t write much or any backend code. The problem usually isn’t the library itself and that’s true of GraohQL. It’s the cargo culting of GraphQL & other new tech that might be unnecessary or overengineering for your specific use case.
dmitriid 6y ago
> I'm as much opposed to adding more incidental complexity to the frontend as the next guy, but GraphQL has objective purpose and makes a lot of things much simpler By moving all that complexity to the backend. It's not luddism to call this out. > Learning new things and doing things better than they were done a year before is an essential part of being a professional software engineer Yeah, no. It's not "better than they were done a year ago". It's just dumping all the complexity in somebody else's lap, reimplements a bunch of things from scratch, poorly, and calls it progress.

mjmahone17 6y ago

This is really cool! I love seeing GraphQL back in its roots as a way of improving the developer experience for native iOS apps. From what I understand, this project tries to solve one clear pain point that isn't solved elsewhere: Swift developers can use GraphQL in Swift without writing GraphQL directly. Being able to create idiomatic operations through Swift is nifty to see. Somewhat interestingly, it seems like to solve other problems, @maticzav is independently following similar paths that the original developers of GraphQL in Objective-C followed. Some of the highlights: - Using code generation to make access patterns more type safe. - Creating a centralized set of Type Models, that map 1:1 with the schema the app accesses. - Mostly separating the GraphQL operations (in this case, as written in Swift) from the models a component interacts with: the components just see that they have a Schema-based Type Model. I'd personally think about using the query-creation API to produce query (and fragment, once those are supported) specific models for consumption. The problems of both over and under fetching may expose themselves when more than a couple interactions are operating with different views over the same types. I've talked about why Facebook no longer recommends Type Models before: https://www.youtube.com/watch?v=Vo8nqjiKI3A https://www.youtube.com/watch?v=Vo8nqjiKI3A It's really encouraging to see the recent explosion of ideas for "how to do GraphQL": I'm not sure what sort of synthesis these myriad projects will create for the broader community.

adsharma 6y ago

Re: Conways law at Facebook I was at Facebook when GraphQL was invented, maintaining a backend storage service where a core assumption was that storage should be reorganized based on access patterns and that predicates should be pushed down to storage where they can be executed more efficiently. GraphQL was hard to push predicates down, because you don't know which of the edges were written in PHP. My response was fquery[1], which is like what's being discussed here but with python as the source language instead of swift and amenable to preserving the largest possible query structure for backend optimizers, including SQL optimizers. It has some early demos converting a GraphQL/fquery into SQL where possible. It should be possible to add enough metadata to fquery to identify if an edge is non-trivial (calls into another microservice) or trivial (can be optimized to a storage backend or SQL). [1] https://github.com/adsharma/fquery https://github.com/adsharma/fquery