[DISCUSS] Revamp JanusGraph Management

Jan Jansen <faro...@...>

Hi everyone,

I started nearly one year ago to investigate how we can revamp JanusGraph Management.

Why do we want to revamp JanusGraph Management? Schema Management and Index Management is buggy
and hard to refactor without introducing breaking changes.
For users of programming languages other than Java, we don't have any solution currently.

I came up with two basic idea's:
  • Schema Management using Gremlin
  • Http Admin API using (GraphQL/GRPC)

Schema Management using Gremlin
Most of the databases allow schema management using the default query language.

  • Known query language

  • To be able to support management tools in different languages, we would have to port queries for all languages

  • A massive number of internal classes have to be exported as public.
  • Refactoring wouldn't be straight forward which prevent as to change the schema class without breaking changes. (class types and order is saved in the database)
    A solution would be to implement a new Graph class from the ground up and map internal vertex types to newly created vertex types.
  • This won't allow tasks such as index repair, or reindex.

Http Admin API
GraphQL and GRPC both allow us to build a new management interface from the ground up with newly created types.

  • Auto generate client libs for different languages.
  • Step by step implementation
  • Allows adding health check endpoint which can be used by a Docker health check or Kubernetes liveness checks.
  • Long-running tasks can be solved using streaming in GRPC and subscriptions in GraphQL, such as repair or reindex.

After adding an admin API and revamping the internal implementation, we could come back and add a Gremlin based schema management.


  • What do the community members think about it?
  • Do you see other advantages or disadvantages?


Join {janusgraph-dev@lists.lfaidata.foundation to automatically receive all group messages.