361–370 of 413 posts
I've replaced all of these with Go + SQLite: 1. Intercom 2. Zendesk 3. Email marketing 4. Kanban 5. Todo 6. Our billing stack 7. Our issue tracker 8. Our forum 9. Uptime monitor 10. PagerDuty (clone) I have dozens of products I sell, so I thought: why not build everything ourselves? All of these run on the same server and use very little memory. I replaced all the SaaS tools we used with these. I also moved to dedica…
Earlier quoted context omitted.
Could you share a bit more about your learnings on go + temporal? That combo was next in line for us to migrate _to_
Sure, basically: - Temporal itself is written in Go and we use Go for our backend so we expected this to be a natural fit. - Temporal makes writing activities in Go very explicit and boilerplatey - This in turn makes testing more difficult than it needs to be often - Temporal doesn't play well with Go's concurrency model at all (all stuff like goroutines needs to go through its special workflows.Go) a lot more often…
Earlier quoted context omitted.
> Depending on how your code is written, modifying code baked into workflows becomes complex, as anything that modifies the history event ordering breaks determinism in already-deployed workers. I see this as Temporal surfacing inherent complexity of the domain in a way that forces the developer to consider it, rather than introducing extra complexity. If it didn't make workflow determinism a strict requirement, the…
Actually Temporal does have a way to avoid determinism called rainbow deployments. If you're fine with deploying several versions of workers (and are on a reasonably new version) you can just avoid the determinism issue altogether with their k8s controller. If you do need to have some long workflows, there is an explicit hook for "what happens to existing workflows on version upgrade". But to be fair - none of the ot…
Earlier quoted context omitted.
You seem to have a rather limited understanding of what kinds of concurrency exist and how those needs are best met. Whether something is a server or not is not very relevant to this discussion. SQLite is an excellent production db for many real world workloads, as has been widely documented. It is very different to Postgres, so requires learning a whole new skill set. One way to think about it is that SQLite can wor…
> SQLite can work well for the parts of your system where there is naturally strong partitioning. Or the parts of your system that don't have big data and no need for massively concurrent writes. And that's the vast majority of systems!
I don't understand this obsession with SQLite for real, production apps. SQLite is an embedded database, completely unsuitable for managing concurrency. This is what database _servers_ are for, e.g., Postgres, MySQL, etc. Their entire job is to allow you to modify data from multiple processes, on different machines, at the same time. This is a foundational principle of computer science. It seems to me that the "SQLit…
For me, I have a use case that needs to support a few thousand users, probably a few hundred concurrently. The combination of SQLite (libsql, a concurrent implementation of sqlite) and Rust means I can do so from a $2/m VPS and a single server instance. Backups are done via a cron job that uploads to S3. Does it pass the "Netflix scale" test? No But it doesn't need to. I'm not profiting from the service and SQLite of…
Earlier quoted context omitted.
If an app needs a database, it gets a database server container, instead of getting a user and database on a shared database server as things used to be done. Every little django app has its own postgres container. Every wordpress site gets its own mysql container. That is the modern way. Those database containers get a PVC/volume/mount for their data dirs. The only thing ever connecting to them is their "owner" appl…
And when you need to scale to thousands of instances of your microservice?
Honestly, this whole leys run loads of nodes seems to have sprung up from languages that are slow oe don't have decent concurrency.
Earlier quoted context omitted.
Yeah this is the part I don’t get. It seems like people are talking about 1 distinct app = 1 container and this is the new normal? We’re back to managing cows instead of cattle again?
I just think a lot of people here haven't ever worked on large scale systems. They don't know what the don't know.
Earlier quoted context omitted.
I was thinking of using SQLite on top of k3s/Longhorn to replicate it. Anyone do something similar? Folks mention light steam and aws but Jeff Bezos’s biceps are too much for me to handle.
I'll echo the other response. I've had pretty terrible experiences with SQLite and Longhorn/NFS. It's just not the right database for pretty much ANY network based filesystem, where the locking primatives aren't as robust, and you might get two processes trying to hit it at the same time. Frankly - they say this themselves: https://sqlite.org/howtocorrupt.html As someone who runs a fairly big personal cluster backed…
Earlier quoted context omitted.
sqlite is great for the contacts app on your phone, but that's it. Hipp even said that it is not a replacement for a real multi-user, concurrent RDMS. Its primary competitor is "fsync".
SQLite is able to handle tens of thousands of write transactions per second on modern hardware. That is probably similar to or more than your real, multi-user, concurrent RDBMS.
Earlier quoted context omitted.
you just made me realize how much i wished people stopped talking in abstractions and just stated what they were doing. i hadnt realized how often i saw things like "workflows" and just kinda had my eyes glaze over. none of it ever really clicks until i see the true descriptor of whats going on. ive been over here using claude relatively simply as of recent, just claude code and i might enter plan mode to do some big…
Check out Matt Pocock's coding workflow. His approach is repeatable, consistent and is backed backed by actual theories in large software development.