[DISCUSSION] Moving gremlin-visualizer under JanusGraph

[porunov]

This discussion is about moving gremlin visualizer under JanusGraph to have a default gremlin visualizer out of the box.
I'm opening this discussion here for an attempt to reach original authors @prabushitha and @umeshjay and hopefully get some feedback about it.

At Mapped we have a fork which includes the following:

• Added support for different graph traversal names.
• Added GitHub actions to build & push Docker image.
• Added productions mode to host in Kubernetes.
• Added ability to override default values (graph host, port, name) via environement variables.

Public fork from Mapped with the included changed can be found here.

The proposal is to move the fork under JanusGraph for wider acceptance and easier graph usage out of the box.

Changes applied at Mapped were made by @vavsab and @Yevhenii-Kozlovskyi1

Would be great to hear some thoughts about this plan.

Discussion in janusgraph-dev.

[prabushitha]

@porunov Thank you for reaching out and looping me into this discussion. It’s great to see the enhancements Mapped has made to the Gremlin Visualizer—especially the added support for customizable graph traversal names, Docker build and push workflows, and Kubernetes compatibility. Moving this fork under JanusGraph sounds like a solid approach to make these improvements more accessible to the community and streamline setup for end-users. I’m supportive of this plan.

[porunov]

Thank you @prabushitha for the amazing work you have done in developing this visualizer.
I answered to @amcp below, please, let us know your preferences.
You might want to leave the original repository as is to have more control on developing visualizer without following policies in JanusGraph.
In this case, we will just have a link to your original repository for users who want to explore both code bases.
Otherwise, if you think you want you repository to be managed by JanusGraph then we can manage the transfer and by default GitHub will re-direct urls automatically from the previous repository to the new repository.
I'm good with both approaches, but would be good to know your preference.

[prabushitha]

I'm good with the 1st approach, so that Janusgraph community may in future update the visualizer with specifics to Janus. You can rename it to any name that aligns with Janus repository guidelines.

[amcp]

The licenses of the original repository and the Mapped fork appear to be permissive (MIT License). I do not want to whine about a new package, especially a visualization (yay!) but the proposed repository does not appear to contain any tests. Would the name be janusgraph-visualizer? Are all the dependency pull requests listed in the original repository fixed? should we triage and import relevant issues in the original project to add as backlog to janusgraph?

[porunov]

Thank you for feedback @amcp !

the proposed repository does not appear to contain any tests

So far there are not tests, but it was tested manually and the image is available in Docker registry (currently under Mapped organization): https://hub.docker.com/r/mapped/gremlin-visualizer/tags

Would the name be janusgraph-visualizer?

I'm good with any name, including the original name.
This visualizer can be used to visualize data from any Gremlin-enabled graph databases.
Thoughts about janusgraph-visualizer - it will be more clear that this visualizer comes from JanusGraph repositories, but on the other hand people might think that it can be used with JanusGraph-only.
Thoughts about gremlin-visualizer - it points that it can be used with any Gremlin-enabled database, but may not follow the convention we had for other JanusGraph repositories.
Personally, I don't have strong opinion on naming, and I'm OK with any name if someone has preference here.
Would be good to have suggestion from @prabushitha if you have any preference.

Are all the dependency pull requests listed in the original repository fixed

As far as I know all dependencies are resolved as per SOC2 compliance. CC @vavsab
Thus, we can close most of the original PRs except the following two PRs. These two PRs are not implemented at Mapped as far as I know:
prabushitha/gremlin-visualizer#33
prabushitha/gremlin-visualizer#36

should we triage and import relevant issues in the original project to add as backlog to janusgraph?

Some of the issues from the original repository are resolved in Mapped's fork.
If @prabushitha is OK to transfer the original repository under JanusGraph then all the issues and PRs will be transferred automatically. In this case, we can close already resolved issues after rebasing commits from Mapped's fork. Otherwise, we can transfer Mapped's fork under JanusGraph and then manually re-create issues which are not resolved yet (there are only 18 issues, so should be quick to re-create them) and we can reference original issues to keep history.

[porunov]

JanusGraph visualizer is now created here: https://github.com/janusgraph/janusgraph-visualizer/
Thank you everyone and credits to the original author @prabushitha