5 ms·

Rama is extremely fast, as you can see for yourself by playing with our Mastodon instance.

by nathanmarz 3y ago

jitl 3y ago
is there a way to guarantee reading your own writes from a client perspective?
- nathanmarz 3y ago
  Yes. Depot appends by default don't return success until colocated streaming topologies have completed processing the data. So this is one way to coordinate the frontend with changes on the backend. Within an ETL, when the computations you do on PStates are colocated with them, you always read your own writes.
  - teacpde 3y ago
    It makes sense, but wouldn’t the write be slow? Especially when you have many streaming pipelines.
    - nathanmarz 3y ago
      That's part of designing Rama applications. Acking is only coordinated with colocated stream topologies – stream topologies consuming that depot from another module don't add any latency. Internally Rama does a lot of dynamic auto-batching for both depot appends and stream ETLs to amortize the cost of things like replication. So additional colocated stream topologies don't necessarily add much cost (though that depends on how complex the topology is, of course).
jedberg 3y ago
It’s fast until it’s not. Making a post and then hitting reload and not seeing it can be very jarring for the user. Definitely something to think about.
- nathanmarz 3y ago
  What do you mean? Every post I do shows up instantly. Reloading the page from scratch can be slow due to Soapbox doing a lot of stuff asynchronously from scratch (Soapbox is the open-source Mastodon interface that we're using to serve the frontend). https://soapbox.pub/ https://soapbox.pub/
  - squeaky-clean 3y ago
    I think the concern is will this still be true if Mastodon reaches Twitter scale?
    - nathanmarz 3y ago
      Rama is scalable. So as your usage grows, you add resources to keep up. Scaling a Rama module is a trivial one-line command at the terminal. Rama's built-in telemetry provides the information you need to know when it's time to scale.

Rama is extremely fast, as you can see for yourself by playing with our Mastodon instance.

jitl 3y ago

is there a way to guarantee reading your own writes from a client perspective?

nathanmarz 3y ago
Yes. Depot appends by default don't return success until colocated streaming topologies have completed processing the data. So this is one way to coordinate the frontend with changes on the backend. Within an ETL, when the computations you do on PStates are colocated with them, you always read your own writes.
- teacpde 3y ago
  It makes sense, but wouldn’t the write be slow? Especially when you have many streaming pipelines.
  - nathanmarz 3y ago
    That's part of designing Rama applications. Acking is only coordinated with colocated stream topologies – stream topologies consuming that depot from another module don't add any latency. Internally Rama does a lot of dynamic auto-batching for both depot appends and stream ETLs to amortize the cost of things like replication. So additional colocated stream topologies don't necessarily add much cost (though that depends on how complex the topology is, of course).

jedberg 3y ago

It’s fast until it’s not. Making a post and then hitting reload and not seeing it can be very jarring for the user. Definitely something to think about.

nathanmarz 3y ago
What do you mean? Every post I do shows up instantly. Reloading the page from scratch can be slow due to Soapbox doing a lot of stuff asynchronously from scratch (Soapbox is the open-source Mastodon interface that we're using to serve the frontend). https://soapbox.pub/ https://soapbox.pub/
- squeaky-clean 3y ago
  I think the concern is will this still be true if Mastodon reaches Twitter scale?
  - nathanmarz 3y ago
    Rama is scalable. So as your usage grows, you add resources to keep up. Scaling a Rama module is a trivial one-line command at the terminal. Rama's built-in telemetry provides the information you need to know when it's time to scale.