Integration with another web application

[malcolmarnold]

First, thanks to all contributors!

I notice [Roadmap] Embeddable Component #695 , is not currently prioritised, but I wonder what options are there for someone looking to embed graph-explorer in their web app.

Pardon if I am naive, but what is possible with an iframe?

• Prepopulate the graph by supplying query on URL? Even just a starting node would be useful.
• Parent window receives messages when user clicks on nodes & edges?

Other things useful for those looking to integrate:

• Themeing, so that I can make it look consistent with parent app
• Hide Open Connections in top banner, so that connection would be provided and unmodifiable by users
• Hide entire top banner and move Show/Hide Table/Graph View elsewhere, so that the appearance is more seamless
• Provide node/edge styling (env vars?, a file to be customised when creating container image?), so that user does not have to do this
• Hidden node/edge labels (analogue of row level security), so that it's possible to prevent users browsing the whole graph

[kmcginnes]

Hi @malcolmarnold. Thank you for your interest in Graph Explorer.

It seems that your use case would require Graph Explorer to be an integrated part of your web app environment. I believe the best approach for you would be to fork the GitHub repo and customize Graph Explorer to fit your exact needs.

That said, some of the features you requested above have been considered and may be prioritized in the future.

• Prepopulate the graph by supplying query on URL

This is a feature that has been brought up a few times in conversations, so it might happen at some point. However, there may be security concerns as this implies blindly executing a database query based on clicking a link. A nefarious user could embed a delete query in the URL, which could wipe out data in the database if clicked. We'll have to investigate if this risk is worth taking.

• Provide node/edge styling (env vars?, a file to be customised when creating container image?), so that user does not have to do this

This is in our backlog, but not currently prioritized. The current short term solution we are considering is to allow a style config file to be exported from one user and imported by another.

A longer term solution may involve a more centralized approach where the server hosts a shared configuration that all users get. But a lot more work needs to go in to this to ensure a good experience is achieved for both server maintainers and individual users.

• [Roadmap] Persisted and Shared User Settings #689

• Hidden node/edge labels (analogue of row level security), so that it's possible to prevent users browsing the whole graph

The user can choose to do this today using the entity filters sidebar panel. But there is no way today to define these filters in a shared location and prevent the user from changing them. If you fork the repo, the pieces need to accomplish this should be in place.

[malcolmarnold]

Thanks for taking the time to reply, @kmcginnes.

I will fork and begin my customisation!

Prepopulate the graph by supplying query on URL

This is a feature that has been brought up a few times in conversations, so it might happen at some point. However, there may be security concerns as this implies blindly executing a database query based on clicking a link. A nefarious user could embed a delete query in the URL, which could wipe out data in the database if clicked. We'll have to investigate if this risk is worth taking.

There's a lot of value in giving the end user a starting point to explore from. So my reasonable effort-to-value suggestion is to just accept a demilited list of vertex & edge IDs. That seems safe to parse.

[kmcginnes]

@malcolmarnold yes, that is a good alternative approach. As with all things, there are downsides to this approach as well.

• Some databases use sensitive data as the ID value for their data, and putting it in the URL could lead to unintentional data exposure
  • You could encrypt the data, but that requires an encryption setup with a private key managed somewhere by someone
• Some databases use require specially formatted queries to handle integer ID values (gremlin server comes to mind) and URL strings do not encode the data type (everything is a string)
  • You could add a flag to treat the IDs as integers, but it is possible that only a subset of the IDs should be integers
  • You could add a type flag for each ID, but that makes the feature slightly less human editable and friendly
  • You could embed encoded JSON data in the URL, which eliminates any human editability and friendliness

None of these problems are insurmountable. They just make the feature less broadly attractive to work on since there is no clear single path to success for everyone.

This is why we did introduce a feature that allows users to save and load populated graphs. It stores the list of node & edge IDs in a JSON file that can be shared with anyone. That file can be loaded in any Graph Explorer instance that has a matching connection.