elierotenberg

For this kind of tasks I usually create a private Firefox extension which gives me access to extended browser capabilities and the ability to lift some security-related restrictions. I run it in a sandboxed browser, much like I would do with something like Selenium or Puppeter, but I have much more options to hand-tune the automation.

It reminds me of a lightning talk I gave at ReactConf some time ago :)

Basically forward-shuffling the component tree to produce HTML that will be really hard to match using CSS Selectors usually found in adblockers and other DOM-targeting scripts.

Code: https://github.com/elierotenberg/react-armor

Video: https://www.youtube.com/watch?v=n63XXHY4A7I

It seems like monotonicity (or a subset, stronger monotinicity, still covering many practical use cases) can be statically enforced in an algrebraic type system. With some generics magic you can encode monotonicity as a type assertion on (optionally asynchronous) function calls mapping an underlying transport/RPC mechanism (REST over HTTP, RPC over Websocket, custom protocol over TCP/domain socket...).

In TypeScript for example you can strongly type your communication protocol (web requests/reponses, websockets, parent/worker ipc, etc) and get some guarantees at compile time. For example, you can guarantee that your state updates over the wire are eventually consistent.

The same goes of course for other algebraic type systems by encoding monotonicity in the form of static type assertions (Flow, Caml, Haskell...).

Is React Resolver related to React Nexus[1]?

[1] https://github.com/elierotenberg/react-nexus

One really useful pattern is React higher-order components, eg. https://github.com/elierotenberg/react-nexus#componentgetnex...

The pattern is

  function decorate(params) {
    return (Component) => class extends React.Component {
      ... // some code using params
      render() {
        return <Component {...this.props} />
      }
    };
  }

my2c.

This benchmark is indeed very interesting.

I think I may have failed to express my point, though. I'm not building a message queue, as it is certainly a very hard problem that has been engineered for years by people way smarter than me :) I'm merely leveraging the goodness of their implementations (in my case redis, but RabbitMQ is also an option I've considered explicitly in my post).

The chat is a contrived example to show that even under high load, full-scale flux over the wire is a reasonable option. As for "any kind of serious load", well, maybe my example fails to meet the requirements, but unless I'm building Facebook, I think I've faced something serious enough to be able to think about my next step.

Oh, you're absolutely right, 10M/s is a mistake, which I've corrected.

Few remarks though:

- it's still way below the number of actions we're talking about here (~100k/s)

- since redis is only used as a generic MQ and not as a store, it can be sharded at the app level without the pain usually associated with redis clustering

- I've deployed a similar (but less performant) design for the player of a gaming website, which is in use in production for more than a year, and works like a charm (we're talking ~5-50k users per channel on a daily basis). This is definitely a "second-system" pattern, but I try to avoid the associated pitfalls :)

I'd be genuinely interested by your feedback!

Actually this whole stack is designed with SSR in mind, see the related package react-nexus (which I will soon blog about, too!) :)

Unless you need to handle a very small number of concurrent connections, using 1 process per connection seems to be a huge overhead, although I can think of some use cases.

However, I can imagine a similar tool doing multi/demultiplexing, eg the handler process would take input text lines prepended with a connection identifier (eg. "$socketID $message") and output using a similar formatting. Pretty much like websocketd but with multiplexing and unixy/pipe-friendly (eg. you can apply grep/awk/etc before and after).

How would this fit compared to websocketd?