I’ve been working on open sourcing a background jobs library I built for Rust and Postgres, called Underway.[0] Unlike other similar queuing libraries, it offers a simple “step” functions API for defining dependent units of work.
I built this because a number of projects I work on need a robust, resilient way of deferring work but I didn’t want to add another piece of infrastructure or another language to my stack. Plus as soon as you start to reach for APIs that offer some kind of workflow concept, your options become fewer and further between.
> but the 800-pound gorilla in the room is climate change. Where I live, winters are 4.5 degrees warmer.
The George W. Bush administration (e.g. via Frank Luntz) advocated for the term "climate change" because Republican strategists wanted to leverage perceived uncertainty about global warming as much as possible.[0]
This is a PR effort that seems to have largely succeeded (both in adoption and its goals) and it's unfortunate that when we are literally talking about warming we adopt a term that is less precise; you are talking about global warming here.
This is an odd telling of history because the term climate change was also pushed by the scientific community as a more precise alternative because people didn't grasp how global warming could make some places colder with larger temperature swings in both directions.
It's conflating two things, Luntz and Republicans at the time did want to push a narrative of uncertainty surrounding greenhouse gas emissions and they wanted to switch terminology in a pro-environmental move because of the existing connotations surrounding global warming and "environmentalists" made it hard to get any Republican support.
You're not going to gain support/understanding for something, from people who have made up their minds, simply by changing the name of the thing. The same people who were sending chain E-mails in the 90s that said "How could it be Global Warming if it's so cold outside! LOL" are now posting Facebook memes that say "Duh, Climate has always been Changing!" Any new name someone gives it will be equally ridiculed, because its opponents don't care what it's called.
While I understand your point is likely that sidewalks would come before later advancements (like support for bikes) I want to make it clear that bikes do not belong on sidewalks.
If you ride a bike please ride it in the street with other vehicles. This is the law in some jurisdictions (such as where I live) but frequently ignored.
Failure to do this poses a serious risk to pedestrians. Please do not use sidewalks as an alternative road.
I've stopped advising people to not ride bikes on sidewalks, especially opposite the direction of traffic, even in situations where it's legally permitted (for example, kids in my area are allowed to ride on sidewalks).
People get really worked up when you ask them to stop, really angry! Which I find so odd because if somebody comes up to me and says something is both illegal and unsafe, I check the laws, and put some critical thought into what the risks could be, and then typically comply if I'm convinced, or simply respond with "I have heard what you are asking, but it's not absolutely required, so I will continue to do so."
> There isn't a biological proclivity to liberalism!
Yes, but aren't there biological proclivities to certain personality traits, and then proclivities of people to certain personality traits to political ideology?
So if liberals don't reproduce, it could start selection against the "openness to experience" personality trait.
A small, anecdotal example of this... there is a family in my community that is part of the conservative christian organization called "Quiverfull" that believes in having very large families. The one in our community has 12 children. They see it as creating members for their religion but I would be surprised if more than a couple of these kids end up following along (based on who the kids are turning out to be).
Generally, Alpine would handle pure client-side functionality, like toggling classes, expanding a drop-down multi-select, etc.
HTMX for server interactions, fetching, posting updates, etc.
One can accomplish a lot with little to no JS, with the app primarily driven by the backend. Which is quite a benefit if you know and like PHP/Python/Go/Elixir/C++ better than JS. Or just don’t like working in JS.
I'm coming around to building everything for a VPS from the outset. There's a lot of upside to VPSes, such as:
1. Can be purchased as a fixed cost, usually at a rate that's much cheaper than on-demand pricing, and especially serverless--this tends to only get better with time as competition keeps prices low
2. It's "just" a Unix/Windows/Mac box, so the issues with runtime constraints you mention are bounded differently (and often more favorably); serverless is also just a box, but the constraints tend to be more onerous and limiting and it's not usually accessible in the same way
3. With containers, it's trivial to move between providers, so the hardware itself becomes fungible
4. On containers, I'm having a great time shipping Docker Compose configs--this works really well for the scale of application I'm targeting while avoiding the dreaded complexity of e.g. k8s
5. There's decades of high quality tooling already built and battle tested which makes operating VPSes much easier; the fact you can SSH into the machine, for instance, has huge leverage as an solo person working on independent products
Going forward, I'm planning to skip edge compute altogether unless there's a really compelling reason to want it. I should also mention that when a VPS is paired with a CDN, you can layer on bits of "edge compute" where it's warranted; or, you know, use it to cache static assets close to your users. :)
All-in-all it's kind of a funny return to where I started ~20 years or so ago with web development.
> it's kind of a funny return to where I started ~20 years or so ago with web development
It's a journey I've been going on too.
All the new platforms and paradigms that have emerged have had an initial shallow aura of helpfulness that has drawn me in, but almost exclusively when digging in I've realised that they create more issues than they solve, and/or introduce limitations that aren't worth it and force me to write janky, overly complicated code to work around that isn't comprehensible even a few weeks hence.
Maybe the most notable exception to this is containers. But in a sense they're an abstraction over the very same VPS paradigm. So that makes sense. It's not something new or different, just the same thing but with some advantages (and disadvantages too, obviously).
If VPSs had the same marketing and maybe a bit more polished standard tooling I have a feeling it would quickly gain traction and simplify life for most people. As well as prevent vendor lock-in, of course.
It’s in the SaaS business model. The incentives, even for fully open source like supabase, is misaligned with self-hosting. Even if they’re super honest and trying to be helpful, their fully managed globally available offering is going to have very different needs than self-hosters.
I actually more like the model of having FOSS where the company behind it offers consulting instead, to build, deploy and operate the product for customers who lack the in-house expertise. It’s not perfect, but it helps align the incentives towards simplicity.
It's also just generally wrong to build a scheduler on top of the docker API. We have CRI for a reason, because everyone knows Docker is not going to be around forever. Certainly not the company. Maybe dockerd.
> usually at a rate that's much cheaper than on-demand pricing
This is an area that is legitimate swindling/inflation by hosted app providers (e.g. DO Apps, Heroku, Render, Fly, etc). Oftentimes the per-vCPU/memory price is inflated over the underlying cost, even relative to a rather expensive underlying provider like AWS; which they'll reasonably justify by saying that this is the value-add, yeah you pay more but its more managed. But: when you have underlying access to the VPS, you can host more than one process! Which, of course, they're oftentimes doing on their end to cut costs.
Serverless functions can legitimately fall into the "always cheaper" category. If you've got twenty apps that each get request volume in the range of dozens-to-thousands per month; you could host that on a $5/mo VPS, or you could pay a few cents for a FaaS (Lambda, GCP, Cloudflare Workers, etc, all priced in the same magnitude). But the price-to-scale chart of serverless functions is really weird; they do hit a point where they're more expensive than just, you know, running a web server on a VPS. That point isn't at a super low volume, but its not far off from where its something to think about for a typical software organization. If I had a personal project that hit that point, I'd classify it as a good problem to have.
I also feel endless frustration in how there legit isn't a single cloud provider out there that (1) offers a serverless functions runtime, and (2) gives you the ability to set a non-zero budget which turns off the world when you go over budget. Many offer free tiers with no credit card, and some are even generous (Vercel and Firebase are two good examples), but I won't build on a free tier. I want to pay you. So, you upgrade and give a credit card, and now you're liable for one fuck-up bankrupting you, or throwing you on your knees at the mercy of their customer support. The severity of this fuck-up ranges from "my GCP account does just use a VPS, but egress is unlimited, so the bill was a bit high this month" to "the new dev changed a lambda function to call another which called the first one, and our bill is now the GDP of a developing nation-state".
The vast majority of the managed infrastructure world is, unfortunately, B2B swindlers just trying to out-swindle each other, only possible because they're all buying from each other, constantly raising prices, finding new ways to bill their customers, and losing any grip on the true (extremely low) reality of their costs. Supabase is better than most. I really do appreciate releases like this one. I'd also add Cloudflare to my list of "good ones"; they've taken a hard stance against charging for bandwidth, and I think that single decision had controlled a ton of the incremental costs we see from their newer higher-level product offerings like Workers.
This is incredible. If I understand the thread, that >$22,000 surprise bill was not forgiven by Vercel and the most they're willing to do is offer a 25% discount.
Is Vercel a business or a scam masquerading as a tech company?
If a company needs to stoop to this level of billing shenanigans to make money, I have my doubts...
Vercel have controlled the narrative that, managing your own infrastructure is too difficult or, it takes too much time away from shipping products. They want you to put your trust in them, but you’ll have to pay for it. This would be ok if you could trust them.
Many stories are emerging where it’s clear that trusting Vercel is a risky strategy.
Actually I reached out to you asking for a comment which I could add to the article, not for your technical support.
I was surprised and I have to admit a bit dismayed to watch you throw yourself into the fray on a Sunday. The technical issues, which in fact persist, are at this point an aside to the way Vercel has handled this issue.
You can reference this comment for the article if you'd like. I'm always more than happy to help out folks. Based on all of the information you've provided, everything is working as expected. As I mentioned above, I'm happy to continue investigating if there is a new repro showing unexpected behavior. Thanks Max
It’s pretty clear these issues were beyond what traditional support was capable of. If you had reached out to someone like Lee earlier it’s likely your experience would have been much better
Vercel’s definitely in a weird place, trying to be the home for innovation while also offering more traditional support. While the support experience you had was less than ideal, you’re also failing to recognize that you are bleeding edge a bit here.
Your reply here makes it really hard to take any of what you’ve done in good faith. Lee has been incredible to work with and I commend his efforts here
In fact Lee was looped in six weeks ago; there was an issue with Remix and CDN cache behavior which popped up on GitHub. I mentioned my issues in that thread thinking they were likely related. Lee responded and let me know he would talk to the internal team.[0] However, Lee did nothing that was ever visible to me. Moreover, I completely disagree with your assessment: it should not require Lee or social media posts to tackle issues like this, that’s completely unscalable and not a realistic way to run a business.
It’s pretty irresponsible of you to be suggesting folks reach out directly to Lee when frontline support fails. That sucks for Lee and it’s bad for the Vercel business.
To be blunt with you, your comment does not read well. It looks like you’re ignoring very real problems and doing everything you can to dismiss them as “bad faith” when in fact there’s a demonstrable problem which shouldn’t be excused as growing pains but instead addressed head on. This kind of fanboyism doesn’t help anyone and I hope Vercel takes the time to reflect on this feedback and make real, meaningful changes.
I'm currently stuck in their support hell and have been told:
1. My issue is not real
2. Okay, your issue is real, but because I'm not paying $$$ we're going to ignore you
3. I should do free work for Vercel and poll their community forums to see how widespread the issue is
4. Their support is only trained to handle frontend issues and because this is an issue with their CDN it's expected that they'll respond incompetently
5. They'll escalate with their CDN team and respond in one week (that was over a month ago, no follow up whatsoever)
It's hard to take Vercel seriously. As a toy, it's probably fine. But I'll ultimately move this project off of their CDN product as soon as it reaches costly volume.
I built this because a number of projects I work on need a robust, resilient way of deferring work but I didn’t want to add another piece of infrastructure or another language to my stack. Plus as soon as you start to reach for APIs that offer some kind of workflow concept, your options become fewer and further between.
[0]: https://github.com/maxcountryman/underway