design: Sub-Graph Modules (sgm) about landscape-graph

[jexp]

That's why labels are like tags. You can add them on the fly and they are useful to tag things, group them or denote status etc.

So you don't have to create a complex ontology structure just tag your nodes with the labels that represent the roles they play.

[halcyondude]

Hi there! I had a look at Apollo Federation, and while it's pretty cool, I'm not sure it's the best fit here, most specifically because subscriptions are not supported. However much of the conceptual information on Schema composition is quite relevant and makes sense.

For now to keep things simple, and not have another layer of indirection, planning to use graphql fragments and a simple directory/manifest approach.

Another concern I had on using Apollo Federation is the impact on the client/query layer, as well as requiring a gateway, the supergraph/subgraph idiom and such to be part of the runtime. In the ideal case (I posit) the compositional model for the data layer is immaterial to the final data model without coupling.

[halcyondude]

@halcyondude That's great! Are you planning on centralizing everything into a single database vendor (in this case, Neo4j for now)?

Using Neo4j for the time being, primarily due to existence of APOC and the GDS libraries, and free availability of Neo4j Desktop as a native experience across platforms, with a low[er] barrier to entry for new contributors. As the GraphQL javascript library does all the translation of GraphQL --> OpenCypher, really the standardization is on OpenCypher, which is implemented by other Graph Databases as well (https://opencypher.org/projects)

[halcyondude]

Update, after findings in #4

The the SGM's implemented (initially) are exposed to the supergraph via GraphQL endpoints. This provides strong typing, and interoperability with a deep canon of existing libraries and algorithms, inclusive of ontology/taxonomy/semantic frameworks, as well as documentation and visualization tools.

A variety of back-end database stores can be used behind that interface. In my view, a graph database w/ the neo4j-graphql javascript library is compelling as it removes the need for writing Resolvers, handling sorting/filtering/pagination, and authoring Mutations. Being able to drop into Cypher via @ directives is a nice escape hatch as well as a way to expose Cypher query capabilities and results as GraphQL.

[AlexxNica]

Hey there, @halcyondude! Congrats on the awesome work and research you're doing! I'm using a lot of your research to guide my own, which I started a while back for a Filecoin Plus project.

Through my research, I'm trying to follow similar concepts you've described, and I feel like the "Sub-Graph Modules" concept would benefit from the Apollo Federation architecture. Do you know about it already? If not, taking a look may be worth it!

Here are some starting points:

• Landing page with a nice overview.
• Documentation explaining the concepts with examples.
• Documentation for "Schema composition" with more in-depth explanation.

One thing, though, is that it seems Neo4j doesn't readily integrate with it, but it seems easy to make it do so. Here's a repository from the Apollo team that demonstrates it working with Neo4j: https://github.com/apollosolutions/neo4j-subgraph

[halcyondude]

https://compiledexperience.com/blog/posts/dynamic-graphql

[halcyondude]

[AlexxNica]

@halcyondude That's great! Are you planning on centralizing everything into a single database vendor (in this case, Neo4j for now)?

[halcyondude]

Recently published, apollo's stack just leveled up in terms of oss offerings...

https://www.apollographql.com/blog/announcement/backend/the-supergraph-a-new-way-to-think-about-graphql

https://www.apollographql.com/blog/announcement/backend/apollo-router-our-graphql-federation-runtime-in-rust

It's likely that after a more detailed review we'll move forward with some of these components.