External resolvers or federations for parts of the Infrahub Graph

[sdktr]

During a very entertaining diner with some great Otters, this concept of a multi-domain graph was discussed. In this post I'll try to summarize what we discussed.

The two most important features of IH (in my opinion) are:

1. Backend: very strong / solid management of a flexible graph database. This includes all the dimensions that make this data valuable like timebased views, branching, RBAC etc.
2. Frontend: a developer friendly representation of this graphDB. This is represented in both a GraphQL API as well as a cool web UI. The SDK and a lot of other features are all based on this.

The combination of the 2 makes for a very strong product for both those intimately involved with data management/modelling as well as the consumers of this data. It is very clear though, that IH's database is never going to store ALL the data that a typical IH consumer is interested in. Examples of data not within IH database are:

1. historical state data. These are within a TSDB or SuzieQ/Slurpit kind of tool
2. live state data. Resides in the device itself
3. Secrets: stored in a specialised Vault for eighter functionality or compliance reasons

The consumers we're targeting would greatly benifit from being able to still consume this data as part of one big SuperGraph, with a GUI/SDK on top.

In the GraphQL world, having a fragmented data architecture is addressed by federating (or stitching) several schema's together into one big graph. Products/companies doing this are WunderGraph, Apollo, Hasura, Grafbase etc. The end result of this stitching is a developer/consumers dream: one big API for everything you need in your product/automation.

Placing infrahub as one of the delegated schemas behind some other graphQL gateway will definitely work. Unfortunately, it will make all the great GUI/SDK features of IH be unavailable for the external data.

Possible solutions for this:

1. a seperate IH frontend, that acts as the GraphQL gateway. It resolves to multiple backends and places the GUI functionalities on top of the schema nodes, limited to the functionality of the subgraph
2. nodes within infrahub store an external lookup placeholder. For the simpler use cases this might work (e.g: 'the location of this secret is at this url')
3. same as 2, both this time IH is able to actually resolve the value.

What are your thoughts on this general issue of using IH as the all-in-one gateway to your complete data domain?