java-wasm-graphs-demo

Geo Hierarchy: Java Wasm Graphs Demo

Live Demo: Explore the interactive demo here.

This project serves as a proof of concept for client-side graph processing utilizing Java libraries, such as Guava and Commons CSV, compiled to WebAssembly via GraalVM. This innovative approach enables the querying of geographical hierarchies directly within the browser, eliminating the need for backend support.

Key Features

Once the geographical graph is established, users can query its data with questions like:

var reachable = Graphs.reachableNodes(graph, "Collo").contains("Algeria");

This line of code leverages Guava's graph APIs to efficiently traverse relationships and return results seamlessly to JavaScript.

Motivation

While JavaScript libraries suffice for basic graph queries, this project shines by allowing powerful libraries originally written in languages such as C++, Rust, or Java to function within the browser/Node environment. This capability opens up possibilities for integrating sophisticated solvers like OptaPlanner, Timefold, or Choco solver, enhancing the web application's analytical capabilities.

Technology Stack

• Google Guava: Utilized for graph modeling and traversal.
• Apache Commons CSV: Efficient CSV parsing for data manipulation.
• gexf4j: Serves as a tool for generating GEXF file formats suitable for graph representation.
• Sigma: Employed to visualize the resulting graph structures.
• Handsontable: A JavaScript data grid for editing data and exporting it to CSV format.

Explanation of Workflow

1. Data Editing: Users edit geographical data through a data grid interface.
2. CSV Generation: A CSV file describes the hierarchical relationship between geographical entities.

   Skikda, Algeria
   Collo, Skikda
   

3. Query Submission: JavaScript sends the CSV data and queries to a web worker for processing.
4. Graph Processing: The Java/Wasm/Java runtime listens for messages, parses the CSV, constructs the graph, and processes the query to derive answers.
5. Graphic Representation: The results, along with the graph, are returned to update the user interface interactively.

Limitations

• Current bundle sizes are moderate, with a non-debug size of 10 MB and compressed sizes of 4.3 MB (gzip) and 3.4 MB (Brotli).
• WebAssembly modules load asynchronously, which requires listeners for readiness events.
• Certain issues with JavaScript object cloning may pose challenges when interfacing between the Java and JavaScript realms, necessitating the use of libraries like Gson for data serialization.

Future Directions

This project represents a step towards enhanced web capabilities. Ongoing efforts include improving inter-operability between Java and JavaScript through GraalVM, alongside potential developments for implementing multithreading capabilities for improved performance.

For additional context on GraalVM and WebAssembly, consider exploring the following:

• GraalVM meets WebAssembly by Fabio Niephaus
• GraalVM Demos Repository

Engaging with this project provides insight into the potential of merging mature Java ecosystems with modern web technologies, significantly enriching web application capabilities.