181–190 of 334 posts
- A single VPS server to host the app. I love DigitalOcean.
- A single docker-compose file to bring up the entire stack containing the front-end, the back-end and the database.
- Caddy for automatic SSL certificates and proxying.
- JavaScript/TypeScript for building stuff.
- Cloudflare For DNS
Earlier quoted context omitted.
If you haven't checked out App Engine in a while, you really should. Especially check out the App Engine "Flexible" editions, which make it really easy to run on App Engine withOUT getting locked in. I run a NodeJS GraphQL server in App Engine Flexible, and it is basically just like running it in a Docker container. It's also pretty trivial to run in Google Cloud Run if I so desired, there is even a tool to assist: h…
If you're just now looking in to GAE, you should likely be using Cloud Run instead. My company is busily migrating everything there and reaping the benefits.
Earlier quoted context omitted.
If anything, vendor lock-in is consistently underblown .
The thing Ive learned is that a lot of people have both a vested interest and a sort of stockholm syndrome with vendors (cloud or otherwise). If you spent tons of time learning AWSs special tooling, you are going to see everything as a nail if you catch my drift. Ive seen a few particular users here spend many threads defending their choices despite the often very logical criticisms levied against the "cloud everythi…
Not to mention “resume driven development”. Recruiters love cloud experience.
Earlier quoted context omitted.
That's right, I'm exaggerating. At current rates I'll hit that limit at 7.5MM pageviews/month. I've also paid for extra builds once or twice in the past (automatically charges a few dollars when you cross the build time limit), and I pay them $9/mo for analytics.
How much is 1MM? I'm unfamiliar with that suffix.
Great writeup. How do you handle database migrations when using an otherwise automated CI/CD flow with gradual deployment?
You can use any normal DB migration tool. For k8s, I put the app's readiness probe to false, run the migrations and then toggle the probe back to true. Here are some migration libraries: Go - https://github.com/golang-migrate/migrate Node - https://github.com/salsita/node-pg-migrate
is it even possible to do blue/green deploy if your schema changes radically?
My one-man-SaaS setup: - Static frontend hosted on Netlify (free unlimited scale) - Backend server on Google App Engine (connecting to Gcloud storage and managed DB via magic) I realize I'm opening myself up to vendor lock-in and increased costs down the road (if I even get that far), but I've wrangled enough Docker/k8s/Ingress setups in the past to know it's just not worth the time and effort for a non-master.
1. Firebase Hosting for the React frontend
2. GraphJin (Automatic GraphQL to SQL Engine) on App Engine for the backend
3. Cloud SQL Postgres for DB
My one-person SaaS architecture: It’s a Rails monolith deployed on Heroku. I’d rather have the time to build new features for my user base than spend it learning how to use k8s or wrangling AWS through its abysmal console website.
Do you think you're better than the OP because you're using a simpler stack?
Just that a simple stack that's boring can work well for a SaaS whose success is not contingent on huge traffic.
For many successful SaaS companies, if their model is not monetizing huge traffic through ads, traffic is really not a metric of success. And they can be financially successful handling only paltry traffic.
Lots of business-problem-solving apps fall into this space. Sure, maybe you only have 60 customers using your app. But if each one is paying you $1,000 a month...
Earlier quoted context omitted.
If you're just now looking in to GAE, you should likely be using Cloud Run instead. My company is busily migrating everything there and reaping the benefits.
So, this what scares me: in 5 years someone using GAE would be busy with two migrations: classic GAE -> flexible GAE -> and now cloud run?..