-
Graphaello
A Tool for Writing Declarative, Type-Safe and Data-Driven Applications in SwiftUI using GraphQL
There's also:
- Relay-swift: A port of Relay to Swift - 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
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
WSDL2Swift
Pure Swift alternative to WSDL2ObjC making a SOAP request & parsing its response as defined in WSDL
-
It also generates API structs from the schema. The problem is that it's hard to reuse structures that you've generated in your application model. You can read more about the pitfalls in the F.A.Q section of the repository.
https://github.com/maticzav/swift-graphql#what-are-the-pitfa...
-
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