ruslan_talpa

Spin up your hasura instance using a docker container in something like fly.io or whatever you use do run docker containers (you can email me if you want)

I’ve got a lib/executable that you spin up and it gives you a rest api (read and write) for clickhouse if you are interested

Put them in a jar?

Interesting example. I was thinking about this more in the direction of "protecting the IP/investment" rather then "abuse the users" but i get your point.

With the telegram example, i don't see it very much different from a SaaS where you get to talk to an API however you want. My question was more in the space where the customer gets the entire codebase (to deploy it themselves) where just the core is closed (or proprietary with maybe source available)

would seeing the source for the core (but no rights to alter/reuse) improve your opinion as to "doing some scam"?

Sorry for the late reply, my email is in my profile (and the link to the product if you want to see before contacting me, though in would prefer to get in touch either by email or discord that you can find on the main page)

I think i’ve built just that, can we get in touch? I would appreciate the feedback

Over the time (as part of researching competition) i also hear a lot of fans of retool with rave review (though never specifics as to what they are using it for). And i get it's appeal for building the UI, drag and drop, you see it directly and all the props of all components are there in the UI with documentation. But putting together the UIs is not what i find hard (using libraries like Reach-Admin). For me it seems way more time consuming having the UI interact with the actual backend/db and when i see in retool that this is done by "write a bunch of SQL for each table/button/screen" and they are just there in a list ... i just don't see how this is scalable/manageable for a internal tool with 10-20 screens. Also all the input validation is on the frontend ... did i miss some docs somewhere?

* localStorage is small, volatile, OPFS is big/durable

* main thread <-> db vs main thread <-> worker <-> db:

  - firstly, sqlite with OPFS has to run in a webworker

  - even if it was possible to run in main thread, this approach allows for a code structure that is similar to a traditional architecture (frontend/backend split) and it's easy to route some request to the web worker while let over request fall through and reach backend server and not needing to worry about that in the "frontend code"

in principle yes, i agree but one aspect the desktop apps lose, the distribution model. it's way easier to just say "go to this link" and the app is running (no install step, no central store, no "code signing").

since this is basically running in a (modern) browser, doesn't it follow that it works on all platforms where there is a browser?