If you’re doing that honestly, where they really have that problem and you actually have a good solution, you’d be a jerk not to lightly pitch it at that point.

You could probably do that up to 100 or so customers reasonably easily.

It’s easy to get carried away building every request, especially with early adopters who likely aren’t actually invested yet but may be excited about their own vision for it.

My personal experience is that too much of it leads to the product becoming a sort of shapeless, unwieldy ooze. Or perfect for one customer and few others. Some things can be tough to undo later too, so you might end up supporting them a lot longer than you’d like.

It makes connecting user domains to your app easy and reliable at any scale. Each Approximated user gets the own globally distributed, managed cluster of servers with its own dedicated IPv4 address. Includes (unlimited) edge rule features, DDoS protection, webhooks, and more. Make a simple API call, tell the user to point an A record at the IP, and it’s connected to your app with its own SSL certificates.

Built/building with elixir and phoenix, which has been fantastic.

I would argue that the answer to questions is no. It depends on how you define “smarter”, though. You would likely gain knowledge writing the essay yourself, but is gaining knowledge equivalent to getting smarter?

If so, you could also just read the essay afterwards and gain the same knowledge. Is _that_ smarter? You’ve now reached the same benefit for much less work.

I think fundamentally I at least partially agree with your stance. That we should think carefully before taking a seemingly easier path. Weighing what we gain and lose. Sometimes the juice is, in fact, the squeeze. But it’s far from cut and dry.

I still think it's the best way to live, but the saying "do what you love and you'll never work a day in your life" really is double edged.

Currently working on:

- Further improving the embeddable DNS widget (to help/automate users updating their DNS records) that launched last month

- Rolling out the new hybrid self hosted version that allows traffic and certs to only go through your servers, while getting the full benefit of the cloud version

- Tinkering with some AI ideas for improving the existing WAF features (tricky, but potentially powerful)

- Making Edge Sequences (pattern matching and rules applied at the edge) more flexible and powerful with more composable options and ways to match requests

Recently hit a milestone of over a million domains served!

I already automate apps, machines, etc with the machines API and GraphQL, so my big worries in this area are:

- Woops, some bad logic deployed too many machines (sounds like this policy helps) - Some kind of mistake or attack that just explodes bandwidth usage suddenly

Coming up on a million domains served, it's been a fun ride!

Concurrency? Trivial.

Reliability? Unbelievable. (YouTube Sasa Juric's "Soul of Elixir" talk)

Clustering/horizontal scaling? Built in, even across networks.

Web framework? Competitive with the best (I'd argue better, with liveview but YMMV).

AI/ML? Amazing support and tooling.

Embedded/IoT? Incredible support with the nerves project.

There's only 2 places where I feel it falls down a bit:

1) brittle dev tooling in ElixirLS that trips up new and experienced devs alike. Soon to get better though as competing LSPs are in the works.

2) no official release-as-binary tooling yet. Things are way better in the last few years for releases, and you're probably containerizing anyways, but I am jealous of e.g. Go's single file binaries.

Most of the world is more urban than not: https://ourworldindata.org/grapher/urban-vs-rural-majority

My pixel 5 just stopped turning on one day about 2 years in, and my pixel 7 pro had the volume and power buttons fall out about 3 weeks in (not due to a drop, after googling it's apparently a very widely seen issue).

The service with iFixit was unhelpful, they told me "We keep seeing this and Google says this is wear and tear. We can't submit it for a warranty repair, and if we try we end up eating the cost". After finally complaining on twitter I was contacted by some support person who said to give iFixit this email and they would fix it. They still refused, and after a few more rounds of interactions like that I eventually bought some replacement buttons on Amazon, popped them in, and put a case that covers them on it. I'm fully expecting this to randomly die some time before 2 years is up.

Combine that with Google's extremely strong tendency to abandon everything, promises like these seem well, worthless.

Meanwhile my daughter is using my wife's old iPhone from 8 years ago. My Samsung note 3 and my s8 still boot up and work just fine (though I cracked the screen on one about 5 years ago). It's just so obvious that these phones are very low priority to Google, while other companies base their business around their phones.

Jokes aside, and coming from a place of ignorance, it's interesting to me that a file count that size is still a real performance issue for git. I'd have expected something that's so ubiquitous and core to most of the software world hasn't seen improvements there.

Genuine, non snarky question: Are there some fundamental aspects of git that would make it either very difficult to improve that, or that would sacrifice some important benefits if they were made? Or is this a case of it being a large effort and no one has particularly cared enough yet to take it on?

Cloudflare SSL for SAAS is also another option, though (and I'm biased here) there's quite a bit locked behind their enterprise plan, which jumps the cost up significantly. We have an article describing the differences here: https://approximated.app/approximated-cloudflare-comparison (Obviously biased towards us, but also backed up by links to their docs for each point)

Finally, you can build and self-host your own service to do this if you want. I'd recommend https://caddyserver.com for it if you'd like to go that route. It will handle a lot for you, and is very well designed - we use a customised version of it under the hood. That said, it's still something you'll need to host, sort out dynamic config updates, and monitor. Custom domains, especially securing them, can have a lot of unexpected issues crop up at random times.

Caddy will do a lot to try and deal with those, but if you're doing this for very long or at any kind of scale, you'll run into some pretty obscure issues that are usually caused by external factors (like a CA suddenly revoking a bunch of certs, or changing the way certs can be verified). It can be stressful trying to figure those out while your custom domains are down, and they're usually hard to predict. A paid service will almost certainly be cheaper, easier, and much more reliable unless you dedicate engineers to maintaining it. For instance, Approximated starts at $10/month, or about the price of the VM/VPS you'd host Caddy on anyways.If you're going to be scaling up, we also give automatic volume discounts for every 1,000 custom domains.

https://www.mitchellhanberg.com/the-comprehensive-guide-to-e...

I discovered a lot of things in this post that made me see them as much more valuable than I'd originally thought.