3 ms·

Thank you for this link. All the blogs always talk about "leadership", "design", "team management" and the like. This people do, despite saying in the last part

Thank you for this link. All the blogs always talk about "leadership", "design", "team management" and the like. This people do, despite saying in the last part of the article that figma's strength is a well-performing c++/rust webassembly+webgl backend. Let's get some details on what mattered here.

joeycodes 4y ago
Having worked on the performance bits of that code base, I always appreciated that the well-performing parts wouldn't have happened without leadership setting explicit performance goals and allocating resources to pay for monitoring and much engineering time to reach said goals.
- candiodari 4y ago
  If you worked on it ... is there some doc describing the general architecture? It looks like the "frontend" is typescript + c++ and the backend is ... perhaps rust, with rust being a sort of "document server". Like: one instance of the backend code manages one savefile, for potentially many clients that then see eachother's changes. How does webassembly <> backend communication work? I imagine it's somehow websockets. How do you proxy websocket connections to the appropriate backend? How does the C++ <> rust communication work? Protobuf perhaps?
  - paulgb 4y ago
    > How does webassembly <> backend communication work? I imagine it's somehow websockets. How do you proxy websocket connections to the appropriate backend? I don't think there's much public info about this, besides what you can infer from looking at what goes over the wire (zstd-encoded binary messages). But to your question about routing wss connections to the appropriate backend, we've been working on a proxy/DNS server that does just that (by giving each backend its own ephemeral hostname). We've talked to some Figma engineers and at least on a conceptual level they do something similar (although their routing is path-based rather than DNS-based). Our source is here if you're interested: https://github.com/drifting-in-space/spawner https://github.com/drifting-in-space/spawner

joeycodes 4y ago

Having worked on the performance bits of that code base, I always appreciated that the well-performing parts wouldn't have happened without leadership setting explicit performance goals and allocating resources to pay for monitoring and much engineering time to reach said goals.

candiodari 4y ago
If you worked on it ... is there some doc describing the general architecture? It looks like the "frontend" is typescript + c++ and the backend is ... perhaps rust, with rust being a sort of "document server". Like: one instance of the backend code manages one savefile, for potentially many clients that then see eachother's changes. How does webassembly <> backend communication work? I imagine it's somehow websockets. How do you proxy websocket connections to the appropriate backend? How does the C++ <> rust communication work? Protobuf perhaps?
- paulgb 4y ago
  > How does webassembly <> backend communication work? I imagine it's somehow websockets. How do you proxy websocket connections to the appropriate backend? I don't think there's much public info about this, besides what you can infer from looking at what goes over the wire (zstd-encoded binary messages). But to your question about routing wss connections to the appropriate backend, we've been working on a proxy/DNS server that does just that (by giving each backend its own ephemeral hostname). We've talked to some Figma engineers and at least on a conceptual level they do something similar (although their routing is path-based rather than DNS-based). Our source is here if you're interested: https://github.com/drifting-in-space/spawner https://github.com/drifting-in-space/spawner