Browser network graphs: What is state of the art?

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?

1 Like

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.

1 Like

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:

ISB | UCSD | MSKCC | Pasteur | Agilent | UCSF | Unilever | Toronto | NCIBI | NRNB

This is now in progress. First off:

The main version of sigma is not maintained anymore indeed, but the v2 branch is under active development:… We use it in production in multiple projects at @ouestware, and I know people at @medialab_ScPo as well. Link to the tweet

1 Like

Hi @melancon,

Just to clarify past and current Sigma situation:

  • Neither myself or Guillaume Plique (the other Sigma developer) has never worked for Linkurious
  • We both keep developing Sigma, but on a new version
  • This new version is based on Graphology for model and algorithms, and focuses on interactions and rendering
  • I now work at OuestWare, where we actually can develop custom features or integrations for Graphology or Sigma

Let me know if you need more info about the new Sigma version. Hope you’ll find the solution that fits your needs the best.


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. :slight_smile:

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.

1 Like

Sure, it would be a pleasure!
You can ping us at contact[at]ouestware[dot]com, and we can then plan a meeting.

1 Like

@hugi, also this:

We built an initial support for Cytoscape: GitHub - RedisGraph/cytoscaperedisgraph: Cytoscape plugin for RedisGraphLink to the tweet

1 Like

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 :slight_smile: It’s a small, really small world … isn’t it?

Pinging @jason_vallet so he can join in and learn about your work.

1 Like

This is super cool!

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.

A couple of days ago I had a very interesting call with @jacomyal and Paul Girard from OuestWare.

Some takeaway points:

Paul Girard was at médialab Sciences Po until recently, where he worked on projects like “The Web: a digital research field for Social Sciences?”. He also worked with some of the people that were cited in our SSNA paper, but due to a computer malfunction I lost my notes - help me out @jacomyal? He was very interested in that we are using ethnography rather than the NLP approach.

@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

Have we not sworn off Neo4j?

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.

1 Like

Oh! I had no idea. :frowning: