This actually looks very useful. Cloudflare seems to be brining together a great set of tools. Not to mention, D2 is literally the only sqlite-as-a-service solution out there whose reliability is great and free tier limits are generous.
There is always one thing that bites you because Cloudflare is different. I just built an AI game (sleuththetruth.com) and the primary reason it's so slow to prompt a new board is actually not because of AI latency. It's because CF workers have a limit of 6 connections (including spawned workers). There is no way to gulp down all the wiki images I want all at once. If I had put the backend on Railway I don't think I'd have this issue.
You can farm out the requests to a bunch of Durable Objects. Each DO will have a separate six-concurrent limit. And you can send unlimited concurrent requests to Durable Objects. (This is not an exploit, this is working as intended. The concurrency limit exists to prevent creating excessive connections from a single machine; farming to DOs means the requests are spread out.)
Also note that as of recently, the concurrent limit applies only up to the point that response headers are received, not during body streaming.
Agreed -- except that all of their docs and marketing pitches it for use cases like "per-user, per-tenant or per-entity databases" -- which would be SO great.
But in practice, it's basically impossible to use that way in conjunctions with workers, since you have to bind every database you want to use to the worker and binding a new database requires redeploying the worker.
If you want to dynamically create sqlite databases, then moving to durable objects which are each backed by an sqlite database seems to be the way to go currently.
And now you've put everything on the equivalent of a single NodeJS process running on a tiny VM. Next step: spread out over multiple durable objects but that means implementing a sharding logic. Complexity escalates very fast once you leave toy project territory.
D1 reliability has been bad in our experience. We've had queries hanging on their internal network layer for several seconds, sometimes double digits over extended periods (on the order of weeks). Recently I've seen a few times plain network exceptions - again, these are internal between their worker and the D1 hosts. And many of the hung queries wouldn't even show up under traces in their observability dashboard so unless you have your own timeout detection you wouldn't even know things are not working. It was hard to get someone on their side to take a look and actually acknowledge and understand the problem.
But even without network issues that have plagued it I would hesitate to build anything for production on it because it can't even do transactions and the product manager for D1 openly stated they wont implement them [0]. Your only way to ensure data consistency is to use a Durable Object which comes with its own costs and tradeoffs.
> And many of the hung queries wouldn't even show up under traces in their observability dashboard
How did you work around this problem? As in, how do you monitor for hung queries and cancel them?
> D1 reliability has been bad in our experience.
What about reads? We use D1 in prod & our traffic pattern may not be similar to yours (our workload is async queue-driven & so retries last in order of weeks), nor have we really observed D1 erroring out for extended periods or frequently.
> How did you work around this problem? As in, how do you monitor for hung queries and cancel them?
You just wrap your DB queries in your own timeout logic. You can then continue your business logic but you can't truly cancel the query because well, the communication layer for it is stuck and you can't kill it via a new connection. Your only choice is to abandon that query. Sometimes we could retry and it would immediately succeed suggesting that the original query probably had something like packetloss that wasn't handled properly by CF. Easy when it's a read but when you have writes then it gets complicated fast and you have to ensure your writes are idempotent. And since they don't support transactions it's even more complex.
Aphyr would have a field day with D1 I'd imagine.
> What about reads? We use D1 in prod & our traffic pattern may not be similar to yours (our workload is async queue-driven & so retries last in order of weeks), nor have we really observed D1 erroring out for extended periods or frequently.
We have reads and writes which most of the time are latency sensitive (direct user feedback). A user interaction can usually involve 3-5 queries and they might need to run in sequence. When queries take 500ms+ the system starts to feel sluggish. When they take 2-3s it's very frustrating. The high latencies happened for both reads and writes, you can do a simple "SELECT 123" and it would hang. You could even reproduce that from the Cloudflare dashboard when it's in this degradated state.
From the comments of others who had similar issues I think it heavily depends on the CF locations or D1 hosts. Most people probably are lucky and don't get one of the faulty D1 servers. But there are a few dozen people who were not so lucky, you can find them complaining on Github, on the CF forum etc. but simply not heard. And you can find these complaints going back years.
This long timeframe without fixes to their network stack (networking is CF's bread and butter!), the refusal to implement transactions, the silence in their forum to cries for help, the absurdly low 10GB limit for databases... it just all adds up. We made the decision to not implement any new product on D1 and just continue using proper databases. It's a shame because workers + a close-by read replica could be absolutely great for latency. Paradoxically it was the opposite outcome.
* D1, but agreed. I wish Cloudflare would offer a built-in D1-R2 backups system though! (Can be done with custom code in a worker, but wish it was first-party)
No downtime snapshots would be the best but I'd be quite happy with a blocking backup on a set schedule that can be set from the GUI / from the cli / from a config file. Its a huge PITA having to play 'trust me bro' to clients and their admins with custom workers and backups.
I currently stream it D1 dump -> worker(encrypt w/ key wrapping) -> R2 on a schedule, then have a container spin up once a day and create changesets from the dumps. An external tool pulls the dumps and changesets.
Per their own docs, D1 is primarily meant for things like Auth DBs that you have frequent read/write access to but that store limited amounts of data.
If you need more storage, running Postgres somewhere else and querying via Hyperdrive is probably what you want to do instead.
Most website content management systems would never get close to that size. If you need a bigger database, D1 is probably the wrong solution to begin with. 10GB can be millions of records depending on your table structure. But if you are gathering some survey data, running a CMS, etc. you probably should be fine with even just a few MB of data; which is probably the sweet spot for D1.
> For those who don’t use Workers, we’ll be releasing REST API support in the coming weeks, so you can access the full model catalog from any environment.
Cloudflare seems to be building for lock-in and I don't love it. I especially don't understand how you build an OpenRouter and only have bindings for your custom runtime at launch.
Yes but that is just a tiny part of the whole CF worker ecosystem. The other services are not open source and so the lock-in is very very real. There are no API compatible alternatives that cover a good chunk of the services. If you build your application around workers and make use of the integrated services and APIs there is no way for you to switch to another provider because well, there is none.
nevermind, I see what's happening in the UI. Each `jj` change is preserved in the UI and we can see multiple versions of the same change. The stack then is not really a stack of PRs but a stack of changes (where each change has its own history, i.e., the interdiff view). Did I get it mostly right?
yes, thats right! when you submit a branch, you can choose to "stack" it, so the individual commits in the branch turn into separate PRs. these PRs evolve individually, can be merged individually, and be reviewed individually. you can also set different reviewers/labels for different PRs in the stack.
Nothing is insurmountable; however each one of us must play within the practical constraints of our local geographies (political, social, financial and physical). The parent comment probably means that Switzerland is in a positive on all axes unlike the rest of the world.
It’s politics. Boil most things down and the technical is inconsequential when compared to the politics.
Look at the political system of Switzerland and you will see a radically different setup.
And I think that’s the horse. The rest is cart. Yes they are rich but why? Yes they are relatively stable socially but why? Decentralised Canton government structure + direct democracy (referendums all the time for things that matter). That, I think, is why all the rest.
From a philosophical perspective, I love the cantonal/direct democracy model. But it's supported by a strong culture of awareness of current affairs, and involvement in the political process. (Of course, these two aspects are likely strongly synergistic.)
However, I'm not sure this unique political structure explains the trains running on time, the sensible choices made about the internet structure (per the article), the top-of-the-world healthcare system, the Swiss cheese science institute, or many other aspects of the broader country. It may partly explain the routinely excellent government bureaucracy (say that with a straight face anywhere else!), the convenient and reliable local public transport options, and the local police being well-resourced to the point of apparent boredom.
Heh, you were walking right up to my viewpoint and then turned away. A parliamentary democracy with proportional representation has way more influence IMO, and you'll find another couple of relatively well-run countries that work like that.
My take on AI-apps is that now its possible to build apps that we kind of wanted to build, but never did because it was too inconvenient.
I'm stealing this idea from this paragraph [1]:
> The book points out that the major value in a flying car (as with supersonic) would not be in taking the same trips you do now, only a bit faster. Instead, it would be in taking the trips you don’t take now, because they’re too inconvenient.
There were a few rough edges for me with the block-based editing. I chocked it up to me never having used a block-based editor with any frequency.
I stay away from some of the AI features:
- One feature generates additional context for a flashcard as you practice. This burned up my AI credits like crazy and added nothing but distraction to my practice.
- Another AI feature for PDF summarizing just didn't work. It made a claim immediately and clearly contradicted by text in the exact area I was highlighting.
I strongly empathise with your situation. The definition of security and success in south asian countries is wildly different from that in the West. I’m 28 and I moved to the UK, 3 years ago. I did a bunch of open-source work and found an employer who hired me based on my contributions and was willing to sponsor my visa. Other than going to university, open-source contributions are the only option people like us to move to the West.
I understand why you feel like everything is chaotic. But, remember that most people don’t have the kind of time you have (you are only 19 and can afford to take a lot of risks). There maybe many things that are not in your favour, but you also have things that give you an advantage over others. I didn’t even know HN existed until I was 24. Ignore the chaos, focus on yourself. Apna time ayega.
reply