I'm always excited by the idea of rendering jsx from Python in the same process. Mostly as a bridge between eg. an existing Django app and full SPA React land. You'd swap out the scrappy Django string templating with jsx, then once a page passes some frontend interaction complexity threshold shift it over entirely (with shared components between both). Could this project help achieve this or are imports/build processes etc too much of an impediment?
I've made React applications using Python via Transcrypt, but wrap component functions in a Python decorator that make direct calls to React.createElement() instead of using JSX (example: https://github.com/JennaSys/tictacreact2). It's possible to use JSX with this approach as well, but IMO it starts to get messy and defeats the purpose of using JSX in the first place.
I’ve often wondered about an automatic codemod that takes a Django template and turns it into an API endpoint + React component that does the same thing. Your {% if request.user.is_superuser %} checks get propagated to protecting the API data within. Frankly, though, the impetus to upgrade is often accompanied by a design rework anyways. But I do think it would be viable!
Thanks for the comprehensive reply, does the following argument stand up at all? (Going on the assumption that LISTEN is one more concept and one less concept is a good thing).
If I have say 50 workers polling the db, either it’s quiet and there's no tasks to do - in which case I don't particularly care about the polling load. Or, it's busy and when they query for work, there's always a task ready to process - in this case the LISTEN is constantly pinging, which is equivalent to constantly polling and finding work.
Regardless, is there a resource (blog or otherwise) you'd reccomend for integrating LISTEN with the backend?
In a large application you may have dozens of tables that different backends may be operating on. Each worker pool polling on tables it may be interested on every couple seconds can add up, and it's really not necessary.
Another factor is polling frequency and processing latency. All things equal, the delay from when a new task lands in a table to the time a backend is working on it should be as small as possible. Single digit milliseconds, ideally.
A NOTIFY event is sent from the server-side as the transaction commits, and you can have a thread blocking waiting on that message to process it as soon as it arrives on the worker side.
So with NOTIFY you reduce polling load and also reduce latency. The only time you need to actually query for tasks is to take over any expired leases, and since there is a 'lease_expire' column you know when that's going to happen so you don't have to continually check in.
It's based off of the DBSP paper, which counts Materialize's Frank McSherry as an author. Definitely not ready for the prime time, but any feeback welcome!
I didn't - I wanted to build something I could understand, and the rust implementation comes with a load of (reasonable) complexity, some resulting from the execution model, some from performance requirements.
stepping has 3 Zset implementations - in memory, sqlite and postgres. Currently considering whether to write a small rust one.
It's still possible to get furniture made in the area - https://www.untothislast.co.uk have a workshop at the top of Brick Lane that you can visit. They also deliver by cargo bike which can look pretty impressive for the larger items.
It has been pointed out that this is apparently similar to Djikstra's algorithm although when it was written the author wasn't aware of that.
The inspiration for the algorithm comes from a solution to a problem set in a mid 1980s edition of A&B Computing magazine.
