We are starting to prepare for an overhaul of Graphryder, both the backend and the dashboard. Up to now, we have used Sigma.js to render the graphs in the browser. This has served us well, but the Sigma.js library has not seen any updates for more than two years.
Building new dashboards on a library that has been left to rot might not be a good idea. It may be the case that Sigma.js is actually being well taken care of and that no updates have been necessary for two years. We should look into this, and if not we should try to figure out what a replacement library could be. @melancon, @jason_vallet - are you aware of any new state-of-the-art libraries for in-browser graph viz? Maybe @felix.wolfsteller has an idea?
If not, are there any active communities (StackOverflow, Redit, etc) that could be good places to ask?
Hi @hugi, Sigma indeed suffers from being abandoned. The reason is simple, the developer joined Linkurious a while ago. Linkurious now commercializes Ogma, a library built on top of Sigma (it may also differ in ways I ignore …).
There are a few alternative to Sigma. We (Jason and others) have looked into Cytoscape. @jason_vallet can probably tell us more.
Ah, that explains it. If the world is now lacking a high quality open source library for browser graph viz, that is in itself actually quite a good candidate for applying for funding if anyone feels like building it.
@alberto, you are in the data science crowd on Twitter. Would you be up for tweeting this thread and asking for recommendations? Maybe tagging Salvatore Sanfilippo, mentioning that we are looking into using RedisGraph? RedisLabs might know something.
Indeed, Cytoscape seems like a good call. Specifically the Javascript implementation. And it won’t be abandoned anytime soon:
Funding for Cytoscape.js and Cytoscape is provided by NRNB (U.S. National Institutes of Health, National Center for Research Resources grant numbers P41 RR031228 and GM103504) and by NIH grants 2R01GM070743 and 1U41HG006623. The following organizations help develop Cytoscape:
Hello again and welcome Alexis @jacomyal . Posting here was very considerate of you, and is much appreciated. Also thanks for Sigma, we have been using it for years.
Good news, all around! I like that OuestWare are committed to FOSS. Maybe we should have a call some day and talk about potential collaboration? We have some projects coming up where we could really use a technical partner on the graph viz side.
Thanks Alexis, I just had a chat with Benjamin Hogg who is sitting next to me (we are both part of the Explo-SHS week in La Rochelle) – he is the reason why I knew you had posted on this thread It’s a small, really small world … isn’t it?
Pinging @jason_vallet so he can join in and learn about your work.
Thanks for pinning me, it is a very interesting topic here. So far I go server-side rendering most of the time, but I totally agree that your scenario demands “direct” interaction.
Unfortunately, also graphviz also suffers rot.
I would’ve betted that there is a stackexchange “Graph Theory” community where I found answers back in the day but … there is’nt.
@jacomyal created Sigma and is currently working on Sigma 2, which will be built on their new Graphology framework. He is particularly interested in working on implementations that allow for the heavy lifting of graph generation to be done client-side.
Main points:
the current Graphryder dashboard needs to be rebuilt with more stable technology, and continuing to use Sigma would allow us to keep a lot of what works while replacing what does not
we currently use Tulip to do the heavy lifting, and I encouraged them to get in touch with @melancon to try to understand how Graphology/Sigma and Tulip overlap.
If we were to do a full rebuild of both backend and frontend, they recommend the GRAND stack. This is particularly interesting, as this is the stack we use for the Realities project, so we know it already.
Next steps:
They will keep us informed about new Sigma releases
They will read the SSNA-stack whitepaper we are working on once it’s ready
We explored the idea to potentially partner up in the future for proposals if we need a technical partner to build web-based graph tools
They will contact @melancon to learn more about Tulip
I’m a little on the fence again now after the experiments we ran with Redis graph. It’s definitely not as mature, and crashed our servers when we accidentally ran erroneous queries. That’s why we halted development with Redis graph - we don’t have a staging server with our Discourse setup, and it’s too unstable to allow in production without some serious limitations.
We also discovered that Redis graph does not yet implement Cypher fully, and that there are features in Neo4j that we would really miss. This means that the promise of “just” reconfiguring Graphryder API to talk to Redis graph probably wouldn’t have worked out of the box - we were starting to find this out when development halted because of the instability of Redis graph.
Neo4js main limitation is that we need to start new instances for each database. But that’s only really because Graphryder needs one database per graph. That’s really an oversight in the architecture of Graphryder. For example, I’m currently working with @JacobKarlsson in the Plato project, and he’s reworking Realities to be multi-tenant, using Neo4j. Doing this for Graphryder would be possible, but the Cypher queries of Graphryder are so complex that I didn’t really see any way to do this easily. It would require a rebuild of the Graphryder API.
However, since the Redis graph method started looking like it would also require a rebuild, continuing with Neo4j no longer seems as unlikely.
