> Periodically merge upstream libgit2 in your custom fork, maintain your custom git server code and audit it for vulnerabilities, make sure everything still compiles with emscripten, deploy it.
There's only a difference here because there exist off-the-shelf git packages for traditional VPS environments but there do not yet exist off-the-shelf git packages for serverless stacks. The OP is a pioneer here. The work they are doing is what will eventually make this an off-the-shelf thing for everyone else.
> Rotate API keys to make sure your database service can talk to your storage service and your worker service.
Huh? With Durable Objects the storage is local to each object. There is no API key involved in accessing it.
> Then I don't even know how you'd backup all this
Durable Object storage (under the new beta storage engine) automatically gives you point-in-time recovery to any point in time in the last 30 days.
> And all that only to end up with worse latency than a VPS
Why would it be worse? It should be better, because Cloudflare can locate each DO (git repo) close to whoever is accessing it, whereas your VPS is going to sit in one single central location that's probably further away.
> and more size constraints on the repo and objects.
While each individual repo may be more constrained, this solution can scale to far more total repos than a single-server VPS could.
It’s internal culture that devalues maintenance and product improvement. Launch gets you promo, maintaining gets you laid off.
I saw a lot of humble and dedicated engineers get laid off in the first round and it was a lot of people who put systems stability over their own promo. There used to be a place for those people, which is part of what made Google a decent place. That’s gone now, things will continue to break as long as fixers take the brunt of lay offs.
Asking for advice: I do not have a multiplayer app, but I have some large, interconnected, denormalized trees on my frontend as user profiles. Think like a tiled layout, where a user can add/remove/resize tiles, and then add a number of components into each tiled slot, each of those having their own profiles too. Multiple "layouts" can exist with different arrangements of tiles, and theres some other complexity with individual tiles referencing and sharing other pieces of state globally.
Making safe updates via regular REST is difficult, as you have to make sure someone with two tabs open isn't going to make an update on tab 1, then another on tab 2 which puts the overall profile into an invalid state. And in general, ordering matters. Skipping an update serverside that was properly applied clientside could break things.
The dumb-as-rocks solution I came up with is to just send the minimal amount of data over that can completely overwrite a particular chunk of state, and place it behind a queue. Usually thats fine, but sometimes thats a lot of wasted data, 50KB when the actual change was only a couple bytes.
I don't need CRDTs for any of the regular reasons, but it seems like it would make state management a million times easier, even for a single user. For one, I'd get syncing between a user's browser tabs, which is good. But moreover, I can just make simple changes to frontend state, and trust that the CRDT is going to negotiate it properly with the server. I no longer have to deal with it myself.
Does this make sense? Or is the overhead required to make something like Yjs work not worth it when I don't even need multiplayer and local-first.
Sure. Spanner is expensive, and your primary job as an engineer (if you work for an enterprise like most of us do) is to generate business value. So, if nothing else, you will run into the cost problems of Spanner. There are also other problems; iirc both DynamoDB and Spanner shard their key spaces, and each shard gets the same quota, and the key space shards all have to be the same size. This means that even though you might have paid for 1000rps, for example, that RPS volume is divided across all your shards, so if you have one part of the key space that gets way more volume than another you end up eating up the fractional capacity of that shard way faster than you intend and you have to either overprovision or queue requests, both of which are not ideal.
At a previous job, we ended up creating a very complicated write through cache system in front of spanner that dynamically added memory/CPU capacity as needed to prevent hot shards; our application was extremely read heavy, and writes were relatively low RPS, so this ended up working OK, but we were paying tens of thousands of dollars a month for Spanner plus tens of thousands of dollars a month for all the compute sitting in front of it. I don't think we ended up doing much better than if we had bitten the bullet and run clustered Postgres because our write volume ended up being just a few hundred RPS, even though the read volume was 1000x that. Postgres behind this cache system would have handled the load just as well and cost less than half as much.
The other thing that frustrates me personally about Spanner is that Google's docs are incomplete (as usual); there are lots of performance gotchas like this that exist throughout the entire service, and they aren't clearly documented (unlike, to their credit, AWS with Dynamo, who explains this entire problem very clearly and has an [expensive] prebuilt solution for it in the form of the DynamoDB accelerator).
KV is a global persistent data store, so reads and writes may have to cross the internet. In comparison, the Cache API reads and writes from the local datacenter's cache. Also, Cache API doesn't cost extra (KV does).
However, better than either of these is to formulate your outgoing fetch() calls such that they naturally get the caching properties you want. fetch() goes through Cloudflare's usual caching logic. When that does what you want, it works better because this is the path that has been most optimized over many years.
I was in awe of a friend using vim, I asked him how someone could possess that power, he promptly gave me a license of https://vim-adventures.com/ and now I can't use any other editor that at least have a vim plugin.
Give the game a go, totally worth it if you want to ease into learning vim, after some time try and use it for everything, even if it fells slow, persist and it will be worth it.
Maybe someone here can help me. There was a GDC presentation in the late nineties or maybe 2000 or so. The speaker was from EA maybe, having worked a lord of the rings game maybe?
His whole pitch, which came with movies, was if someone did Mario in the style of lord of the rings. There was a scene where luigi dies and Mario weeps. Bowser makes a great speech before his assembled armies which finishes with “and KILL THE PRINCESS!”
Can’t remember who or when. Did I just hallucinate the whole thing? Anyone got a link?
"I am credited with being one of the hardest workers and perhaps I am, if thought is the equivalent of labor, for I have devoted to it almost all of my waking hours."
"Our first endeavors are purely instinctive, promptings of an imagination vivid and undisciplined...but those early impulses, tho not immediately productive, are of the greatest moment and may shape our very destinies."
"When I get an idea I start at once building it up in my imagination".
"But instinct is something which transcends knowledge. We have, undoubtedly, certain finer fibers that enable us to perceive truths when logical deduction, or any other willful effort of the brain, is futile."
The Courage to Be Disliked by Ichiro Kishimi and Fumitake Koga is very quickly shaping up to be this book for me.
It's probably highly unpalatable to modern Western sentiments (e.g., one of the chapter titles is "Trauma Does Not Exist") but it otherwise has really original lessons that I haven't seen articulated elsewhere, despite the sometimes overly formal English translation.
> You are an experienced expert in XXX. You always answer questions to the best of your knowledge, but you NEVER provide answers that you are not sure about, or that are not backed up by high-quality sources; instead you say that you can't provide a good answer. Giving trustworthy and correct answers is much more important to you than always having something to say. You keep your answers concise, on-topic, free of boilerplate, and exclude basic instructions that most developers will be familiar with anyway, unless the user asks for more details.
The one that I find easiest to understanding is still the one that I wrote about a decade ago when I first had to work with OAuth 2. All others I understanding by mapping what they said to concepts in mine, and that seems to work pretty well.
that little toy I had as a kid did more to shape my career as than even hypercard.
FTA (and relevant):
> What truly made this the best toy ever made was the amount of patience and perseverance a kid needed to create these animations, just like real animators. This is also why it would later fall from popularity.
Disclosure, I work for FusionAuth, which can both integrate with and compete with Supabase.
Welcome, Supabase, to the world of SAML/SSO. It's a hairy one, but single sign-on is undifferentiated and really great for customers, so I'm glad you joined.
A few thoughts:
* Consider adding identity linking to your roadmap. I noticed[0] that you don't support it, and will create duplicate accounts if someone uses SSO with the same email address that an existing account has. As a model, FusionAuth offers seven linking strategies[1]. This flexibility lets you handle more use cases.
* I'd encourage you (and your customers) to test across as many SPs as you can. SAML is an 800+ page specification and even though we've been offering SAML for over 10 years and have open sourced our bindings[2], we still have edge cases that pop up.
* I'd love to add FusionAuth as a SAML SSO provider to your docs, so will put that on our team's doc roadmap and submit a PR. :)
* Not related to SAML, but I'm glad that you are supporting PKCE. I hope you deprecate the implicit grant; the XSS threat is very real and the OAuth 2.1 spec (still in progress) basically deprecates that grant[3] through omission. Also, we agree that setting cookies (HTTPOnly and secure, please) is a great way to store tokens[4] and that is worth requiring a server side component in applications.
Finally, I understand why this is part of a paid offering; SAML is often used to segment out enterprise customers with $$$. You like to make money, as do we all. But I'd encourage you to think about a free tier because it is so helpful to the user experience. Maybe 1 SAML connection could be part of the base offering?
An eternity ago a particular Linux kernel developer gave a series of "Why user space sucks" talks at Linux conferences. It was just going through strace logs and making fun of particularly bad examples.
At some point I stared a lot at instruction level traces with Processor Trace or LBRs and usually I found some bad sequences in many programs, where things are implemented very inefficiently.
My son started playing games (with me) at 4 yo (partly because we were all locked indoors for months on end).
Anecdotally - and providing you use some discretion as to choice of game - I’ve found it absolutely fascinating to watch both the pace of development of problem-solving skills, and some of the frankly astounding leaps of logic and intuition young kids are capable of. I vividly remember one rock-moving puzzle in Breath of the Wild that had me stumped until he piped up with a proposal that turned out to be the correct solution. Fascinating stuff.
There's only a difference here because there exist off-the-shelf git packages for traditional VPS environments but there do not yet exist off-the-shelf git packages for serverless stacks. The OP is a pioneer here. The work they are doing is what will eventually make this an off-the-shelf thing for everyone else.
> Rotate API keys to make sure your database service can talk to your storage service and your worker service.
Huh? With Durable Objects the storage is local to each object. There is no API key involved in accessing it.
> Then I don't even know how you'd backup all this
Durable Object storage (under the new beta storage engine) automatically gives you point-in-time recovery to any point in time in the last 30 days.
https://developers.cloudflare.com/durable-objects/api/storag...
> And all that only to end up with worse latency than a VPS
Why would it be worse? It should be better, because Cloudflare can locate each DO (git repo) close to whoever is accessing it, whereas your VPS is going to sit in one single central location that's probably further away.
> and more size constraints on the repo and objects.
While each individual repo may be more constrained, this solution can scale to far more total repos than a single-server VPS could.
(I'm the tech lead for Cloudflare Workers.)