Hacker News new | ask | show | jobs
by ironmagma 1106 days ago
I created something like this inside a tech giant once. It never saw the light of day with regard to usership. It's good to see someone doing the same in the open source world.

A brief summary of what I did:

* Python-powered apps, like this

* React was used to handle lifecycle. Basically, I avoided writing any kind of lifecycle management because I just wanted to do exactly what React would do. This was achieved via events firing when React lifecycle events fired. If props changed on the server, I'd send the new props to React to see if it would trigger a lifecycle event. If a lifecycle event was triggered, I'd replicate it onto the server which could again render new props.

* The result was a nice seamless support for both native React components and the newfangled Python components (which could be made up of either more React components or Python components).

* The purpose of all of this was to cater to ML engineers who didn't particularly like JavaScript and just wanted to build their analyses with Python and share them with coworkers. We had an automatic deployment system for them to share these.

* Only caveats were around session management. Much of the state was handled on the server via a websocket, so if your connection dropped, you lost all ability to update the layout. Load balancing was going to be tricky, since the sessions would have to be shared somehow. I was thinking about serializing and deserializing using Pickle but never really got around to deployment.

See also: [Dash](https://github.com/plotly/dash)

3 comments

Oh, I had a case where I had built an ML based recommendation app, and utilized Flask for serving the results on my localhost. Would have loved to use React but my lack of sufficient JavaScript knowledge prevented me from doing so. Your tool seemed to have perfectly catered to my needs!
Dash could probably get close enough as well. It's a bit limited compared to React but provides quite a lot of interactivity. (Plus, the server is stateless which is nice.)
I'll have to give a try then!
The way to solve session management is to just store the state in html forms and send it back to a stateless http endpoint. That way you get a website that behaves the way all websites work, and can scale easily.
The trouble is though that you also have state in Python which can’t necessarily be represented in Javascript, such as a database connection. You could pickle it, but accepting a user-provided pickled value is a security risk. Also, doing so would leak database credentials, and recreating the state on the server every event is expensive anyway (especially when the state is something like a pandas dataframe). It’s better to just have one dedicated machine per application session that holds the state for the duration of the app.
Don't use pickle. Use JSON for stuff you can't represent in HTML forms.

For database connections, large datasets, etc (stuff you can't send off to the browser) use redis.

This is a trade-off between DX and UX. Holding session state means you need sticky session routing, and restarting servers kills your user's sessions. Plus imposing a websocket on your users is a cardinal sin, makes scaling incredibly hard, makes page load times abysmal, makes disconnects a nightmare for both you and your user.

Its fine if you're creating something like stable diffusion web ui though, which is meant to be a single user app.

I find these dogmas to be presumptuous. For the use case, Pickle would be fine. Scaling was essentially a non-concern… it was an internal tool behind a VPN and the usage was below a dozen (and at most would have grown to dozens).

JSON is an alright storage format but it can’t do infinity, nan, or many other values important to Python. Also, you would have to write a reifier and serializer for every value. These simply create a problem rather than solving one.

Not optimizing DX would be a mistake when the whole purpose of the project is to improve the DX by allowing the users to not write JS/React. Once the DX starts becoming that cumbersome you might as well just avoid it by switching back to native React.

ReactPy dev here. We haven't actually landed on how we want to solve this problem yet. We have some ideas though. Would be curious to hear your thoughts on this issue: https://github.com/reactive-python/reactpy/issues/828

We think option 4 looks the most appealing.

Wish I could help, but I never got as far as auth, and it sounds like ReactPy takes a bit of a different direction anyway. Looking forward to digging in but just haven’t gotten to it yet. Thanks for surfacing though!
Cool idea but it wouldn’t have worked for what we were doing. The Python side definitely needed to be on the server because it was dealing with database connections, talking to other services, and doing heavy duty dataframe manipulation.
At some point we'd like to add client-side components to ReactPy. This might be an interesting avenue to explore in that regard.