How to query ComposeDB directly without GraphQL? Support for Cypher querying language?

Hello :slight_smile: been a big fan since 3box days and love the new ComposeDB announcement. I have some questions about developing directly on top of ComposeDB.

  1. How do I query the database directly? The docs only mention the GraphQL API, which i assume is autogenerated from composites, but nothing about accessing the graph natively.

  2. Is ComposeDB actually a graph database? The only thing i see referencing a database structure says that all nodes must run SQL databases.

  3. Are there plans to support the Cypher querying language which is a popular open source language for querying graph databases (mainly Neo4j). I’ve used it in the past and I love it, it feels very raw and close to the metal while also being simple and semantic to read. It would be a huge DevEx improvement to be able to use Cypher + make ceramic compelling to adopt for non-crypto users.

  4. How cryptographically secure is the data stored in ComposeDB if its separate from the Ceramic Network that actually manages permissions? Is it encrypted before storage in the db and only gets decoded after checking permissions on Ceramic Network?

Thanks. Congrats on the launch :raised_hands:

Thank you! I’ll try my best to answer some of the questions here.

  1. The GraphQL APIs all wind up hitting the collection HTTP endpoint on a Ceramic node. That endpoint isn’t super well documented but if you want to try to figure it out from the code you can start here: js-ceramic/ceramic-daemon.ts at cc6d2f2272cf42a2d64bd96c04acbd0e130b1dc5 · ceramicnetwork/js-ceramic · GitHub
  2. Yes, ComposeDB is a graph database because the documents within it can reference other documents and form a graph, and you can use GraphQL to query that relationship graph. At the moment, however, I must admit the types of queries that are currently exposed through the standard APIs are still very limited. Over time we will be adding more advanced query patterns to the GraphQL APIs to allow more complex interaction with the relationship graph between documents. In the meantime, if you have a backend you can always connect directly to the postgres index database and run whatever types of queries you want there.
  3. No immediate plans to support Cypher, but we’d love to support anyone from the community who wanted to add that kind of integration!
  4. Note that all data on Ceramic is public by default. You can encrypt data yourself before putting data into Ceramic (including via composedb) but that isn’t something Ceramic or ComposeDB will do for you currently. So if you’re talking about read-access-control, that is left up to the application to figure out. As for write-access-control, all data in ComposeDB is written to a Ceramic stream which remains the source of truth for the data, and those streams have the same strong cryptographic guarantees as Ceramic has always provided, where each stream has a single DID that is the controller and is the only one allowed to write data into that stream. All updates to any stream in Ceramic (and therefore to any document in ComposeDB) must be signed by the controller DIDs private key.

I hope that helps clarify things a bit! Please let us know if there are any additional follow-up questions!

1 Like

Are there plans to support the Cypher querying language which is a popular open source language for querying graph databases Cypher is Neo4j’s graph query language that lets you love language test retrieve data from the graph. It is like SQL for graphs, and was inspired by SQL so it lets you focus … This guide explains the basic concepts of Cypher, Neo4j’s graph *query language You should be able to read and understand Cypher queries after finishing …supports Cypher, Apache TinkerPop Gremlin and SQL. ArcadeDB has a fully ACID transactional engine and can be used as embedded, client-server and distributed on multiple servers.

Hey @Larisabrownb. At this very moment, we don’t have specific plans for supporting Cypher However, I’ll make sure we discuss this within the team and update the community if we end up adding it to our roadmap.

There was some discussion of the SQL-based index being a “pluggable” system which could be replaced with a Neo4j-based solution.

That’d give you Cypher support.

We just shared a draft of the design for query filtering and ordering. In the “Possible Future Features” section you can see an approach to custom queries written in a language such as SQL or Cypher. Feedback is appreciated.