Bi-directional JSON/GraphQL interfaces

This isn't a feature request; just a question that will help me resolve an architecture question. Say I have an app with a number of separate services, each running in its own environment. These services need to pass some resources between themselves. Is there a way to define the resource with JSON or GQL is such a way that this resource can proxy between two services: client code on one service can make a request on the resource, which then forwards to the second service, with the answer being returned to the client? Just an idle question...
5 Replies
ZachDaniel
ZachDaniel•2y ago
If I understand correctly, yes this should be more than doable. You can do pretty interesting things with custom actions, but you can go deeper with custom data layers (not easy to write at this time, need to go pretty deep to write custom data layers).
ZachDaniel
ZachDaniel•2y ago
For instance, we have a (WIP) json api wrapper data layer: https://github.com/ash-project/ash_json_api_wrapper
GitHub
GitHub - ash-project/ash_json_api_wrapper
Contribute to ash-project/ash_json_api_wrapper development by creating an account on GitHub.
ZachDaniel
ZachDaniel•2y ago
I've also spiked out some "generate resources from Open API spec" work there
Ben RMX
Ben RMX•2y ago
A tangential idle thought is to take inspiration from a related example of Nx.Serving from either Sean Moriarty or Jose -- I can't remember who. Where they presented a set phoenix front ends, which were cluster-connected to a set of backend strongly GPU-powered BEAM nodes running Nx.Serving ... and they just used normal BEAM distributed process mechanism for the front-end->backend service integrations So, maybe it would be possible for a phoenix front-end process to use normal BEAM cluster communications to make RPC requests to Ash-Resources (modules) deployed on clustered backend nodes? The trade-off, of course, is having a BEAM cluster that spans the front-end backend services... different people, different opinions. Or... maybe even a future with "API Stub" generators... which generates an "Client SDK" that has perfect fidelity with the actual backend Ash API (of Ash Resourcess) for the front-end to include as a library... and it just does all the magic, like gRPC, to talk to its corresponding backend service? --- Is this what the ash-json-api-wrapper does? I'm not familiar with the wrapper . Doesn't matter if it's actually HTTP or something like NATS (at-most-once type messaging) under the hood. Interesting hypothetical by pragdave... 🙂
ZachDaniel
ZachDaniel•2y ago
we could absolutely generate a 1-to-1 RPC api to ash resources and it would honor policies/any invariants you've specified (the benefit of building your app this way) TBH it would not even be hard

Did you find this page helpful?