Hacker News new | ask | show | jobs
by impulser_ 991 days ago
Why is it normal in the Typescript community to rely on a lot of other SaaS providers to build a simple application?

This project relies on 4 different paid services. Why?

Why do you need a SaaS to handle your auth, mailing, database, and logging?

Aren't there libraries for these things in Typescript? Why pay for them?

4 comments

Disclaimer: This is my personal opinion/experience. Not all people/startup do this.

In 2018-2020 my company (an FMCG company) asked me to temporarily lead the IT & product team of 2 startups that they invest (as a majority) a few years before. One is a telemedicine and the other is an e-commerce.

Both of them have almost all of their auth, db, etc using other unrecognized newly startup SaaS.

After a few meeting I realized that these startups is "guided" by the VC to use other startups service that the VC invest and in return the other startups will(must) use our service (telemedicine) for their employee.

So all of these startup companies can claim the monthly active users and companies that use their products, we also get the topline revenue and then those numbers will be included in a pitch-deck for the next round of investment.

To top that, for the telemedicine I also got a KPI to hire 200 programmers so we can also include that number in the pitch-deck. In 2 years, I got 3 talented one and less than 30 that can code fizz buzz or simple CRUD (with their language of choice).

Not the dev but i know for me it mostly comes down to not reinventing the wheel, and it allows for a lot easier ability to scale while also allowing for free operation as well for indies.

Turso: Has insanely large free level and means no need to run your own DB(though you can run your own sqlite locally), their free tier even just got drastically expanded.

Clerk: 5000 free users, not having to deal with your own authentication.

Resend: Avoids dealing and managing mail, and dealing with spam filtering etc, i dont know if they allow just using an internal smtp, but seems ok given 3,000 mails per month.

Tinybird, i don't know enough about but also has a free plan...

So mostly i'd imagine most of these aren't about paying for third party platforms, its about offloading tasks you don't want to worry about implementing yourself, and that also give you the ability to scale outside of the small initial deployment for cost.

You don't have to reinvent the wheel. You just have to use a library instead of using a library and paying someone lol.

There are hundreds of auth libraries out there that you can use. Not one of them charges you per user lol. We been doing this for decades. Why are we now paying companies to do it for us?

This can be said about mailing, logging, and databases. I spent decades building web application not once was it hard to implement these features using libraries.

In fact it easier than ever with the tooling with have today.

No wonder 99% of starts up are losing money and going out of business. They are giving all there money away to the few that survive lol.

I guess the typescript people don't appreciate frameworks like Rails, Django, and Phoenix that implement all these features for you lol.

> We been doing this for decades. Why are we now paying companies to do it for us?

Probably for the same reason that every trivially simple web app is now a bloated React SPA - because it's all that many devs have ever known.

They graduate and join companies where everything is built in an insanely over-complicated, over-engineered fashion using fifty layers of complex tooling because "that's how Google does it" and the senior engineers wanted to learn something new. So they assume that this level of complexity is necessary because companies wouldn't do everything this slowly and painfully unless they really needed to, right?

Then they pass this lack of wisdom onto the next generation of juniors, and the cycle continues until no-one remembers that it doesn't have to be this way, to the point where people think that paying $99/month for a third-party tool makes more sense than "having to deal with your own authentication", as if authentication is some huge burden and not a basic cookie-cutter feature that's as old as the internet.

By the way, in Phoenix you can get a fully-featured authentication system for free in literally ten seconds: just run `mix phx.gen.auth Accounts User users` then `mix ecto.migrate`. There, I just saved you hundreds of dollars.

> Then they pass this lack of wisdom onto the next generation of juniors, and the cycle continues until no-one remembers that it doesn't have to be this way, to the point where people think that paying $99/month for a third-party tool makes more sense than "having to deal with your own authentication", as if authentication is some huge burden and not a basic cookie-cutter feature that's as old as the internet.

It's significantly worse than that. You have developer YouTubers now that are megaphoning this exact lack of wisdom out to thousands of developers, either misguided older ones or completely new ones.

The four listed things by one of the ancestors in this thread look like they basically came from one fairly popular YouTuber who advocates for exactly this type of thinking very loudly and with dubious credentials to do it.

> We been doing this for decades

This is rarely a solid argument for doing anything in & of itself. Even less so when security is involved.

> Why do you need a SaaS to handle your auth, mailing, database, and logging?

There's absolutely no reason to require SaaS to handle database & logging, but:

1. For mail, in 2023, it's a defacto requirement, for any app. Sure you can do it yourself, but handling spam filters will be a challenge. Defaulting to SaaS on this is extremely defensible.

2. For auth, in 2023, rolling your own auth that is secure & offers decent MFA is a similarly daunting task. Would it be nice if they offered an optional local auth backend, maybe. Would it be nicer if they offered a choice of multiple SaaS backends, definitely. But it's ultimately pretty defensible.

3. It seems to me the DB can be local sqlite / libsqld (looks primarily aimed at dev envs but at least it's an option).

---

On aggregate though you're right, this does seem excessively SaaS-y.