Alacart

I'm the founder of https://approximated.app, which is a service focused entirely around making this easy, affordable, and reliable. We have a 30 day free trial if you want to check it out risk free. It works with any lang/framework/hosting platform so that you're not locked in to anything. If you have any questions, there's a 24 hour chat widget and email where you can reach an engineer or myself.

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.

A possible counter point to the dislike of comprehension, depending on why you don't like them:

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.

Yeah that's the joke

My thinking is that it would be a bit like email: run your own server if you want, and the other 99% can use any of the zillion hosting services that exist or would crop up to do it for you with the ease of Gmail.

True, but from what I've seen the usernames on every social solution, decentralized or not, are essentially leased too aren't they? Either they're based around a domain you control or they're under someone else's control ultimately.

This is how I've been feeling but I'm assuming there's more to this that I just don't know.

I keep thinking, what if we: 1. Use domains/subdomains as usernames by just... having the content on them.

2. Follow a truly basic structure for index (feed), single post, etc. so that clients know how to consume them easily.

3. For interactions (replies, likes, etc), the client posts them to your own server (or service hosting you) and they're available at a url referencing the original post url on their own domain. ex) mydomain.com/replies/thepostsurl/1

4. It then posts the reply url to the original posts server endpoint, which can accept or not.

5. When a user loads the post, it lists the replies and interactions as a list of links. the client goes and gets their content directly, and renders it.

This would work without any servers actually having to talk to each other or store more than a link for interactions. If you want to confirm the interaction url on receiving a submission, your server could check but it doesn't need to store or cache it.

Am I crazy or would this not work just fine? or, is this what activity pub already is?

In your example, you compare Lambda against a separate monolith for handling the webhooks, but with a monolith wouldn't the comparison be between lambda and just adding a route and controller (or equivalent) to the monolith?

Am I going crazy or were many of these exact comments posted the last time this was linked?

Isn't the main problem that this change forces all software development, regardless of purpose, to be classified as R&E and therefore forced to be amortized?

Codeberg runs go on the frontend?

Considering that elixir is a functional language, it makes sense that it doesn't make use of objects. I'll also push back on the idea that OO is cleaner than functional. OO tends to heavily use inheritance and mutates state in obscure and unintentional ways. Functional doesn't have those issues. Though "clean code" is certainly a vague and moving target.

Yeah, there were a lot of arguments in the comment that were either disingenuous or revealed they are someone who has only minimally used the framework (or maybe not at all). I've been in both Laravel and the Phoenix world, and they're both incredible frameworks. Laravel has an option for practically every battery you could want to include at the app level and it's very well refined. Phoenix brings the batteries included nature of the elixir language and builds really amazing, easy to use features and tools on top of it. They have both innovated in a bunch of areas and have made really great choices when they're using tried true methods instead. Either of them enables even a solo dev to build out a fully featured app from start to finish. They're both easy to get started with and they both can handle any level of complexity you might need.

These days I default to Phoenix because of the built in features of the language and treating realtime (websockets, pubsub, etc) as a first class citizen. And because I think it has far and away the best (and original) implementation of liveview, which is a paradigm I love working with.

Very true, maybe it's not a strong predictor either way.

That does seem like the same arguments that are made prior to just about anything becoming mainstream though. I'm not saying it means nothing that python has so much mindshare, but the same could have been said to pythons predecessors as well. You're right about commercialization not being about technical excellence, in the short term. In the medium and long term, it's the advantages of recent technical excellence that drives a lot of commercialization.

I've worked from home most of my 13 year career, first as a contractor for various clients, later as a full time employee. I definitely noticed an effect about 2 weeks after I started working from home. I was a bit more socially awkward, more anxious about social interactions. The benefits of working from home are huge, I don't know if I'd be willing to give them up, but I've worried about how it's affecting my personality for my entire career.

So many of my hobbies are related to computers or the internet. I moved away from the place I grew up, and all of that has combined to make it hard to meet anyone at all to make new friends with in the real world. I'm married now and have 2 young kids, with even less ability to easily leave the house on my own. I can too easily see a future where I'm 60 with basically no real connection outside of my immediate family, something that I worry about for everyone if we don't figure out some better ways to be social in the real world again.

I'm not sure what the point of this reply is, this topic just struck a chord with me.

Also because one of the best ways to become part of the zeitgeist is to force people to have time to talk about it, anticipate it, and generally stretch things out. You don't get the Lost/GOT/etc cultural phenomena nearly as strongly if you release them all at once.

like others have said, you'd probably write a JSON API separately. One thing I'll mention though, is that the conventional design of Phoenix to use context modules often makes that very easy, in that your liveviews and API can just call the same business logic functions to crud resources.

So first, 300 consistent listens per episode in this area is pretty respectable in my opinion. Niche things like this are more about _who_ is listening rather than how many people.

I'm 100% someone interested in shows like yours, I just didn't know it existed. One major thing you could probably do right away is invite other people with followings in this area as guests. Popular podcasters are generally annoyed by requests to be on their show, but can be a lot more friendly if you invite them on yours. That's because you're doing the work and exposing them to your audience. They'll likely promote it or might even cross post it if you want to. They might have you on as a guest afterwards, someone with that many interviews is bound to have some interesting things to talk about.

The episode you posted as an example of audio quality lately seemed more than good enough for me. As far as burn out, I would maybe recommend actually doing less for each episode, at least until you feel like you can outsource the worst parts. What if you did only the most important parts of post, and cut down post production to an hour instead of 5 or 6? Maybe a tool that auto removes silence, umms and ahs, etc could help a bit here too. Descript for example can do a decent amount of this in about 5 minutes. Good enough in my opinion. Cut out as much post work as you can. I bet you your real audience won't care.

Part of it could also be just shorter recording times. I prefer longer episodes but it seems like I'm the only one. Editing 30 mins of recording is a lot easier than an hour and a half, and people seem more likely to put on shorter episodes (I guess).

Also, just skimming a bit of an episode, I think you overdo the formality of the intro. It sounds too scripted and not like your natural self. Skipping from the intro to a later clip of you speaking, you sound much more natural later on. A lot of people will bail out during the intro if they're just checking you out for the first time and it doesn't hook them much.

The titles should reflect more of what's interesting to the audience, make it the coolest part of whatever they're doing instead of an elevator length description. Are they hitting high requests per second, doing something bleeding edge, serving a lot of users as a solo dev, etc? Combine that with the most interesting part of their stack for the title. Looking at your show notes I can see this stuff is in there, just make it the title.

If you're burning out, try being more selective with guests too. Don't force it. And don't look at it as needing X audience numbers or whatever for success. You're building authority as someone in the industry, getting respect from guests and listeners, being exposed to way more than a normal dev, and so much more. If you're trying to make a living off of the podcast, you'll need to go wayyy more generic and attention grabbing. But I say don't do that. Instead do this thing well and you'll build a name for yourself with the kinds of people who listen to things like this - people in motion, building things, who are excelling in the field. People who are or will be somebody to respect in the industry.Thats a big deal.

Finally, please keep making the show, this is a niche that I've found surprisingly hard to find good content for. I want the technical details, I want the code talk and the deep dive that most podcasts cut out because "people don't want to listen to this". Well, I do and so do plenty of people actually building real things.

I think you may have missed that they do indeed let you sort of self host, in that you can run it on your own AWS resources. They just need access to manage it for you. Which I'd think would cover most orgs requirements out there that would actually use gitpod, but I could be wrong.

I think in this particular case it's maybe not quite as easy as just shipping a container or whatever, because a huge amount of the value and effort is actually the orchestration of VMs/containers/however they do it under the hood. Again, I might just not know enough here, but it seems more like they've constrained their self hosted option a bit to keep it manageable rather than getting rid of it in practice. It also seems like you could just use the agpl licensed open source code if you want?

Finally, it seems unfair to characterize them as having a weak engineering culture when they've managed to create something rather impressive with, I think(?), quite a small team.

This seems like an eminently reasonable thing to do, with the difficulties of supporting self hosted for a product like this on the infinite variety of customer setups. I can't imagine the time sink it must have been trying to support them all, it can't have been profitable.

It sounds like the dedicated version essentially lets enterprises run in on their own accounts while letting gitpod manage everything, which seems like a reasonable middle ground to me. Also sounds like you can still self host, they just won't support it directly as a customer, which again, seems reasonable.

This pretty much sums it up. Narrowing the scope of maintenance is a big deal. Once I'm confident in the quality of a framework, the next question is how likely and how often am I going to need to use escape hatches for this project now and in the medium term. If I expect too many (or too difficult) escape hatches, it's the wrong tool. If I can't find a framework that I'm reasonably confident in that way, only then would I go without. If so, whatever I come up with is by default a framework. It's just probably not going to be as good as an open source one.

I don't think it is more difficult than it use to be. There's more layers in some cases, but most of the time those are abstraction layers that making things easier (or at least attempt to).

I think the difference is maybe one of perception. We can do more so the baseline expectations of users/customers are higher. I also think that there has been a higher growth of people specializing in one area rather than every programmer sort of being a full stack generalist by default. So for a front end specialist, databases and server side may seem like a black box and more complicated than ever. Or someone specializing in kernel programming might think front end is more complicated than ever.

Generally you can still do things the way they were done in the past if you want to. New tools might make things easier and learning them might seem complex, but you don't have to.

You already know me, just not under this username! I try not to put my name directly out on forums like this, but I run https://approximated.app and those 100k+ domains aren't all in one cluster, though some clusters are growing quickly and might be there in a few months. Customers paying for the clusters are generally SAAS or hosting related so they can bring a lot of user domains when they come on board and tend to grow steadily.

As a counter point, I've been running 100k+ domains through caddy clusters with about 1tb of traffic per month (so not a ton, but not nothing). I built and manage that solo with very little maintenance or support, which I think is a testament to how reliable and performant caddy is.

Despite many knocking it here, I think there's at least one significant aspect of the clubhouse/twitter spaces/etc. model of audio chat: the much stronger feeling of connection that people get from being able to literally speak to the big personalities in whatever their area of interest is.

we can debate whether that's good or bad, scalable, a feature or a product. But I think it's undeniable that the emotional dopamine hit people get from that are a lot higher than getting any kind of async response, especially text. It makes it feel much more real. Even if you don't interact at all and just listen, it feels like you're an insider, you've made it into the club, and you could speak up. Like you practically know <insert names>, you were on a call with them earlier today!

That kind of interaction I think we might see a lot more of as a feature for e.g. streaming platforms. People crave it.

Yes, thanks I should have been more clear that I knew that going in. It was the contrast that surprised me. I wasn't sure if the original hunger was just my excuse for over eating, or something I was imagining. But after talking with other people who don't take ADHD meds, I found they had the same hunger level as I do on the meds, but naturally.

This kind of hunger is what I've felt my whole life too, though my weight is still only in the overweight category. I can eat twice, three times what a normal portion is and still feel like I need to eat. I could easily eat multiple large pizzas by myself with no problem at all. There's a scene from The West Wing where the chief of staff describes his alcoholism and how people would ask him how could he drink so much and still want more. His answer is that he doesn't understand how anybody else could not want more. That it's the best thing in the world. And that's exactly how food feels to me.

A year ago I was diagnosed with ADHD (inattentive) and prescribed a very low dose of Vyvanse (amphetamine based). Suddenly it was gone. I'd want to eat at normal times, I'd eat a normal portion but I could easily walk away or I actually just didn't want more. I asked my wife, is this what other people feel like? It really rocked my world a bit. It's one thing to logically know that people experience reality differently, but I've rarely had such a stark example of it.

You can do this a variety of ways, most of which boil down to automating a reverse proxy server and generating acme certs. My favorite is Caddy server if you want to build and manage it yourself.

Things get trickier if you want to handle this well for globally distributed servers, since you'll need to have a cluster of reverse proxies near or colocated to your app servers. That needs an anycast IP address to handle A records for apex domains, and usually you want them coordinating to share certs, cache, etc. efficiently. In that situation I'd recommend reaching for a paid service, since there can be a lot to build and maintain.

Source: I built approximated.app, which is a service that does all of that for you.

Sort of, yeah, but with a heavy focus on businesses who want to offer custom domains to customers of their own apps. For example, how Shopify lets you connect your own domain to their platform (not a customer, just an example).

Also a different business model (pay a monthly rate for servers in however many regions you want) with some different benefits and trade offs. CloudFlare SSL for SAAS didn't publicly exist when I started this, and it's economics ($2 per domain) still don't make sense for a lot of apps.

In the future, I'll probably look at whatever CloudFlare will have a hard time offering under their business models, and do those so that people have options. Even just the same features but with different pricing models can be really useful to companies with different constraints and goals.

I built an API/IAAS (sort of), https://approximated.app, to make it really easy to connect end user's custom domains to any web app.

It offers automatic SSL for unlimited custom domains and subdomains through dedicated reverse proxy clusters. Each comes with a dedicated anycast IP address so that your users can point an apex A record at it and be geo routed to the nearest region of your cluster.

You can add virtual hosts for domains, subdomains, or specific paths through a really simple API and it'll handle SSL and verification automatically in a few seconds during the first request.

It's been really fun to work on, plenty of hard problems to solve and it's been really useful to people, including myself. I had a baby boy this summer so I've had roughly zero time to market it in any way but there's still tens of thousands of domains running through approximated clusters now so it's been growing a little bit at a time on its own.

Current future plans are for edge caching (nearly done), ddos mitigation, and then hopefully something more interesting like colocating serverless workers or distributed apps maybe.