Live data from Hacker News

Show HN: Octopus – a directed acyclic graph for app development

github.com

31–40 of 49 posts

Re: Show HN: Octopus – a directed acyclic graph for app development

#31
Ah interesting, a trip down memory lane! I made something very similar 5 years ago: https://github.com/atlassubbed/atlas-relax. It was an attempt to build a "stronger" version of React (using DAGs) in under 2.5kb, and completely decouple the diffing/rendering engine from the DOM. So think "nodes that can return JSX templates in their compute functions", but the JSX templates don't need to represent the DOM. They could represent anything, like Terraform config since JSX is just a syntax for javascript objects, similar to the hyperscript function `h`. To create React with my framework, I used a plugin (one such plugin https://github.com/atlassubbed/atlas-mini-dom) which registers listeners on nodes' create/update/destroy lifecycle methods. The simple idea is when a DAG node is added and corresponds to a DOM node, add the corresponding DOM element to the DOM. When removed, remove the element, etc. The cool thing was that the "build your own react" plugin is like 20 lines of code since the base diffing/rendering is abstracted away by the underlying DAG engine, so the interface ends up being similar to an AST crawler interface, where you're just implementing listeners as you encounter new/changed tags.

  const { diff } = require("atlas-relax");
  const DOMRenderer = require("atlas-mini-dom");
  const App = () => (
    
      Bonsly evolves into Sudowoodo after learning mimic.
    
  )
  // create a DOMRenderer plugin
  const rootEl = document.getElementById("root");
  const renderingPlugin = new DOMRenderer(rootEl);
  // mount  against the "null" DAG and render it to the DOM.
  diff(, null, renderingPlugin);
The cool thing is you could diff two different DAGs against each other and listen to the delta, like `diff(, , consoleLogPlugin)`. The base library could be used to generate application frameworks as long as your application framework can be thought of as a DAG operating on data. React is an example of such a framework, but so is something like Airflow, so you could write a plugin that lets you build your own kind of Airflow. That was the motivation behind my DAG abstraction -- to make it easy to create DAG frameworks for frontend and backend. Let the base library do all the hard reconciliation work, and you can build application frameworks on top.

Anyway that was all mostly an exercise. I didn't end up using my framework for anything more than a state management solution for React. It handles global data perfectly, although these days React context or hook management is usually enough.

Re: Show HN: Octopus – a directed acyclic graph for app development

#32

I remember working at a company where we had a backend web framework that was essentially a DAG. You could use it to create API's where the caller simply specifies what they want, and the server figures out, through graph theory, what series of processing steps and API calls to other services should be performed (some of which can have dependencies on the results of other API calls and/or processing steps), and the o…

I worked with a framework like that inside Google in Java. Was okay. You’d write a bunch of methods and the framework would wire up annotated method parameters and return types. The main benefit was improved tail latency since the framework would traverse the graph and run the methods with optimal concurrency.

Same downsides as runtime dependency injection frameworks like Guice—the framework would explode if it couldn’t connect the graph.

Some other upsides: you could decorate methods with all sorts of distributed goodness like retries and hedging. The approach also enable reusable methods that you snap into your server.

Re: Show HN: Octopus – a directed acyclic graph for app development

#33
post #32

I remember working at a company where we had a backend web framework that was essentially a DAG. You could use it to create API's where the caller simply specifies what they want, and the server figures out, through graph theory, what series of processing steps and API calls to other services should be performed (some of which can have dependencies on the results of other API calls and/or processing steps), and the o…

I worked with a framework like that inside Google in Java. Was okay. You’d write a bunch of methods and the framework would wire up annotated method parameters and return types. The main benefit was improved tail latency since the framework would traverse the graph and run the methods with optimal concurrency. Same downsides as runtime dependency injection frameworks like Guice—the framework would explode if it could…

That sounds very cool indeed.

Re: Show HN: Octopus – a directed acyclic graph for app development

#34
post #23

I don’t really understand what values such design pattern can bring worth (that will outweigh its own complexities) my experience working with DAGs programmatically (ie not as an abstraction (like in React) but actually handling the edges&nodes of a graph-based abstraction in code) is that it looks nice theoretically but in practice top-down (conceptual) approach like this often tends to over-complicate things would…

state machines are a common example of an explicit graph-based abstraction that people build their code around.

yeah I heard about lib like XState; just not sure what values it actually provides for a team to decide to use it in a real-world app

Re: Show HN: Octopus – a directed acyclic graph for app development

#35
post #9

Almost every modern framework is implicitly modeled as a DAG? It just rarely used that nomenclature. Heck with Elm a whole language exists for that principle. I'm really not sure what's supposed to be different here. As is evident from the repository you obviously know about React and Vue, so maybe try to contrast it to them, or how it fits in in relation to them? To me it looks like you are building a system-in-a-sy…

As I've just written above, React components form a tree that mirrors the DOM. A graph is a much better fit. Nodes in my DAG ressemble "computed" in Vue, where they watch a value and recalculate when it changes, but... in Vue the watched value needs to exist, ie you're responsible for constructing the graph and ensuring no cycles, and the computed value is only available locally, to be used in the template. In my DAG…

> React components form a tree that mirrors the DOM. A graph is a much better fit.

Not all acyclic graphs are trees, but all trees are acyclic graphs. As such this part of your description is confusing.

Your last paragraph does a much better job at explaining how it differs.

Re: Show HN: Octopus – a directed acyclic graph for app development

#36
post #32

I remember working at a company where we had a backend web framework that was essentially a DAG. You could use it to create API's where the caller simply specifies what they want, and the server figures out, through graph theory, what series of processing steps and API calls to other services should be performed (some of which can have dependencies on the results of other API calls and/or processing steps), and the o…

I worked with a framework like that inside Google in Java. Was okay. You’d write a bunch of methods and the framework would wire up annotated method parameters and return types. The main benefit was improved tail latency since the framework would traverse the graph and run the methods with optimal concurrency. Same downsides as runtime dependency injection frameworks like Guice—the framework would explode if it could…

Producer graphs?

Maybe just me but I find them completely unreadable and painful.

I don't really think there anything inherently better about having the framework connect things through inputs and outputs or developer explicitly specifying the connections through function calls.

In both cases the executor can decide how to execute the graph.

Re: Show HN: Octopus – a directed acyclic graph for app development

#37
post #35

Earlier quoted context omitted.

As I've just written above, React components form a tree that mirrors the DOM. A graph is a much better fit. Nodes in my DAG ressemble "computed" in Vue, where they watch a value and recalculate when it changes, but... in Vue the watched value needs to exist, ie you're responsible for constructing the graph and ensuring no cycles, and the computed value is only available locally, to be used in the template. In my DAG…

> React components form a tree that mirrors the DOM. A graph is a much better fit. Not all acyclic graphs are trees, but all trees are acyclic graphs. As such this part of your description is confusing. Your last paragraph does a much better job at explaining how it differs.

I put a concrete example in the sample app. "pizza" depends on "size" and "base". So a DAG, as you point out, is less constraining than a tree. When you shoehorn your state and orchestration into react components, not only do you have to fit them into a tree, it's fundamentally the wrong tree.

Re: Show HN: Octopus – a directed acyclic graph for app development

#38
post #32

Earlier quoted context omitted.

I worked with a framework like that inside Google in Java. Was okay. You’d write a bunch of methods and the framework would wire up annotated method parameters and return types. The main benefit was improved tail latency since the framework would traverse the graph and run the methods with optimal concurrency. Same downsides as runtime dependency injection frameworks like Guice—the framework would explode if it could…

Producer graphs? Maybe just me but I find them completely unreadable and painful. I don't really think there anything inherently better about having the framework connect things through inputs and outputs or developer explicitly specifying the connections through function calls. In both cases the executor can decide how to execute the graph.

Are you talking about this? https://patents.google.com/patent/US7865872B2/en

Re: Show HN: Octopus – a directed acyclic graph for app development

#39

I don’t really understand what values such design pattern can bring worth (that will outweigh its own complexities) my experience working with DAGs programmatically (ie not as an abstraction (like in React) but actually handling the edges&nodes of a graph-based abstraction in code) is that it looks nice theoretically but in practice top-down (conceptual) approach like this often tends to over-complicate things would…

I'm not doing this for fun. Especially since I'm fundamentally lazy (and more of a practitioner than a comp-sci person). I'm looking at custom configurators for complex made-to-measure products with dozens of options, with many interdependencies between options.

Re: Show HN: Octopus – a directed acyclic graph for app development

#40

Ah interesting, a trip down memory lane! I made something very similar 5 years ago: https://github.com/atlassubbed/atlas-relax . It was an attempt to build a "stronger" version of React (using DAGs) in under 2.5kb, and completely decouple the diffing/rendering engine from the DOM. So think "nodes that can return JSX templates in their compute functions", but the JSX templates don't need to represent the DOM. They cou…

That looks really remarkable.
Post reply on HN