Fair points. I'm also generally happy with Git myself.
I've been exploring JJ mainly for its slightly different approach to change tracking (~every change gets tracked, at least initially, rather than just commits).
Stacked PRs also look interesting but I haven't had an occasion to try them out yet.
Before Docker you had things like Heroku and Amazon Elastic Beanstalk with a much greater degree of lock in than Docker.
ECS and its analogues on the other cloud providers have very little lock in. You should be able to deploy your container to any provider or your own VM. I don't see what Dynamo and data storage have to do with that. If we were all on EC2s with no other services you'd still have to figure out how to move your data somewhere else?
This is actually one of the huge tradeoffs and pitfalls of LiveView. Its websocket model is all or nothing.
For example I have a small side project using LiveView where users would typically pull their phone out, quickly record data, then put it away again. But due LiveView only working with a connected websocket they often have to wait ~1s for the socket to reconnect, and get an annoying error message while it does.
I'm sure there's more I could do to configure this but the default at least is terrible. I believe with Hotwire I wouldn't have this problem, my view would just work and then restore the websocket when it can.
I use Phoenix and LiveView for a lot but I wish we could get more of these rough edges polished up.
You might find Hologram interesting for this use case - it transpiles
Elixir to JavaScript so your UI runs client-side. No persistent connection
needed, so no reconnection delays or error messages. Still write in Elixir,
still communicate with the server when needed.
It's early stage with some rough edges, but there are already Hologram
apps in production: https://hologram.page
that’s a really valid point. liveview’s websocket-first model can feel heavy for quick, intermittent interactions like mobile data entry. it shines when the user is continuously connected, but those short bursts do expose rough edges. hotwire’s approach of progressive enhancement and optimistic rendering handles these scenarios more gracefully since the view works independently of the connection. phoenix and liveview are still amazing, but improving these “short session” experiences would make it even stronger.
Hi! Knots just serve up git repositories over an XRPC API. The actual state on disk is really just a sqlite + your git bare repositories—the two can be tarballed and moved elsewhere easily!
We will work on more first party backup/migrate solutions though.
Git repos don't get replicated anywhere. They live on disk, either on our knot server or yours. Knots are essentially our extension to the AT architecture, allowing user ownership of what's essentially "off-protocol data" (git).
Yes that is true, forgot that part. Doesn't help much in colder situations with more layers but for a single layer case, with nothing carried on the back/waist its fine even long term. I just don't do such things much.
I'd say that for any non-toy service, the default is that you do need those things, and would probably be helped by a database that cares what type you said the column had
Can you even redeploy a sevice like this without downtime?
Do you need to redeploy your service without downtime?
Do you need multi-user and remote access?
Why can't you just use a copy of the database when you need to examine it or resolve issues?
None of these things have anything to do with being a "toy" app or not. They are matters of scale and business requirements. But that's the point isn't it? There are plenty of non-toy systems where none of these requirements apply.
Plenty of very successful business and applications could handle a brief downtime for deployment. Plenty don't need multiple users or remote access, plenty have reasonably small databases.
Why would one pick a TinyPilot over NanoKVM or JetKVM?
reply