Technology Choices for My SaaS in Retrospect
thomasbandt.com
thomasbandt.com
Author mentions that there's a single machine for the api, db and nginx; this means the machine is publicly accesible to everyone, and so is the db (although the port the db is running could be only accessible to localhost). I don't really feel comfortable doing that (so I force myself to out the db within a vpc).
How does the author provision the Hetzner machine? Manually? Terraform? Ansible? If something goes wrong with the single machine, how long does it take to rebuild everything from scratch? For me this is very important and I force myself to being able to rebuild everything with one or two commands (usually using Ansible).
Agree with the lack of usage of k8s. For a one-man project, it seems a bit overkill.
And finally, monitoring. After working for over a decade in the industry, I don't feel comfortable deploying stuff to production that is not monitored (e.g., Prometheus + grafana).
Ok, there's also: backups, security updates, and a whole bunch of stuff that still delays my first deployment.
Dokku is basically open source Heroku. Put it on a server, and then just push your application to it.
That being said, when I was a dev lead, the first things I thought about when choosing a technology were the ecosystem and the how hard it would be to find competent devs. You can throw a rock and find a good enough enterprise C# dev in any major city. I would not have chosen F#.
As far as Flutter, Google has the attention span of a crack addled flea and I wouldn’t tie my horse to any platform with a Google specific language or runtime.
Even Google is moving away from Flutter for internal apps.
https://9to5google.com/2021/10/10/google-ios-apps-native/
I’m very much a native framework snob. But I understand the need to have a cross platform mobile platform for a bootstrapped company. Why not use a JavaScript based mobile platform? He already new TypeScript and Typescript devs are a dime a dozen.
Finally, why use Docker for Postgres?
Or I can sidestep all these questions, and just use the same Docker image everywhere, which will give me the same version of Postgres and the same config. I agree it shouldn’t contain any schema/data.
Postgres is an open source product that has some traction, and even if it disappears next week you still have the source.
Linux is starting to catch on and you can even find places that support it.
The POSIX layer is widely implemented and even Windows and Mac have sone level of support.
What I’m saying is, you can choose from a wide variety of databases on pretty much any common OS and most of the features will just work on all of them.
Minor versions of a single database on different flavors of the same OS are not a big deal.
[0] Much more CPU and RAM needed.
[1] You rarely work with a fresh OS install; you'll have to install things, edit files in /etc/ or whatever, set firewall rules perhaps. For me at least, many of this comes with googling, say, "how do I allow an incoming TCP connection for a port range?". Ie, tiny details I don't want to memorize. I'll have to replicate these steps between the dev VM and the prod environment. If I use Docker, I can write these things into the Dockerfile and then just do "docker-compose up" in production, and it will just work. Also, I can commit that Dockerfile into a repo. It makes it much easier for others, or future-me, to understand what the dev-ops setup is like.
> Google concluded that it was time for the latter route, and that Apple’s UIKit had matured enough for internal needs. The company no longer had to maintain most of the custom components that it built out over the years, including app (top) bars, lists, and menus.
This is also reflected in his choice of Xamarin: he "doesn't like" Dart as a language, so he's forced to choose "dotnet MAUI as a platform [which] might not be as mature and capable as Flutter even today". Flutter as well "suffers from many bugs and problems". Is Flutter really that buggy?
https://bashooka.com/coding/javascript-frameworks-for-cross-...
I'll take a bet, use and choose Flutter for a long time.
Anytime that you emulate a platforms UI, if the vendor makes changes, a native widget will take advantage of it a replicated one won’t.
The fact that Google is working on a third operating system (Fuscia) is not exactly a vote of confidence on Google’s ability to focus.
Like I said, you are welcome to distrust Google, but your general assertions are far fetched and stems from Google's product engineering that has to expand and contract its offerings as they are expected to make money unlike its open source projects.
Ever heard of NaCL? Google Chrome Apps? The many abandoned IOT platform (ie Android Things) initiatives? Swift for TensorFlow? App Maker? Fabric? You realize that Google abandoned the original Angular project (AngularJS) and made a completely new incompatible version.
As far as not abandoning “infrastructure projects”, they literally abandoned a physical infrastructure project and left city streets in ruins.
https://arstechnica.com/information-technology/2019/02/googl...
Any of these projects, except angular have the same visibility and impact Flutter has? You're trying very hard to deride Google Infrastructure and its your very generalization that weakens your claims that they should not be trusted. Anyway, I'm done with this thread as far as it goes.
You don't trust them, cool great, but don't make generalizations about what Google is doing because of your distrust.
Angular was “superseded” by a completely incompatible framework causing a major rewrite. Does that bode well for Flutter?
As far as Google not abandoning popular services - remember Google Reader?
Google’s entire promo culture is about engineers and product managers building something new and not maintaining old projects - this is the reason behind 6 messaging apps - three were introduced in one year.
https://www.androidauthority.com/google-messaging-apps-86784...
Not to mention three completely different operating system initiatives - ChromeOS, Android, and Fuscia.
- via Fable (F# to JS Compiler)
- WebSharper (tightly integrated web frontend and backend)
- Blazor/Bolero Server Side (like phoenix live view)
- Blazor/Bolero WASM
We also start to see Avalonia running on WASM, but I wouldn’t say it’s ready yet.
There are a LOT of friction points that are just really difficult for new devs to work out.
dotnet is really, really good at building scalable, fast, secure web APIs but it is mediocre for building web UIs
They are using React, Tailwind, Typescript, Docker, FP etc. which is what you would find in many modern tech stacks.
That's what I love about this "we should only use old tech" argument. There is no specifics, justification or technical basis for any of it.
So you end up wondering how old should my choices be in order to satisfy the crowd.
I’m in the same boat as previous commenter - React et al feels like new tech to me.
But that’s because I’m an old fart who’s been using php for over 20 years.
My point is that what often gets criticised as "new tech" is actually quite old. Hence the stupidity of that argument.
That being said, if someone who doesn’t know “cloud” and has a deadline just to get something done like the author asked for advice, even I would suggest they just throw a monolith on a VM.
If they really wanted the optionality to go all in on AWS later, I would suggest AWS Lightsail - a simple fixed cost VPS that is easy to upgrade to full fledge AWS.
In other words, I agree with his choice of just using a VPS.
Hetzner has very performant, spacious servers for cheap. Provisioning time is usually less than 2 hours. In my experience using their servers over the last 5 years, they are reliable. And since he's using Docker and CI/CD, he can probably easily move to a new physical server if his died.
Hetzner does offer VPS as well, but you pay more for the provisioning speed and the usage-based billing (assuming you run it 24/7). Plus they have much less space and performance compared to the physical servers.
https://accelerationeconomy.com/cloud/amazon-shocker-ceo-jas...
People really overestimate how many companies use the cloud in any form for anything.
From his LinkedIn, it seems like the product is https://taxaro.de
No special knowledge is needed based on the translated site. It is providing chat with encrypted file transfer (and storage?).
At which point storing the files on S3 would have been far easier, quicker and safer.
This very much. For backups, the great crunchtime isn't when you set up the backups and see them appear where you want them. Crunchtime is when your system is in turmoil, and you need to recover what you've lost.
I've seen so many people claim their backups are in perfect order, only to lose data because something broke between setup and recovery.
Plus, as mentioned, there's your backups sorted. Plus, you'll never have to worry about running out of disk space. Plus, you're taking load off your web tier, for something it really doesn't need to handle itself. Plus, massive performance boost on serving those assets over a CDN. Plus, it's really cheap, most likely a fraction of the cost of your VPS(es) or dedicated box(es).
* staging environment for development
* at least another baremetal machine for a copy of production and a loadbalancer in front of them, to prevent from 100% downtime in case your machine is down
Maybe those other things were there, maybe they weren't but it wasn't about what you should do, just what he did.
I don't find it fair to praise your tech-stack for simplicity and being cheap (awesome features btw) and fail to mention resilience. Unless you run a service that can be down 10% of time for example. Not the case here I guess since we talk about SaaS.
However, I wonder about the choice of React (or any SPA framework) if you say you are not designing for scalability. You said that the product is quite basic/boring and I have yet to see how this wouldn't be much easier to produce in any MVC server-side framework than any frontend framework.
If you are used to .Net, you could choose dotnet core MVC (was that around then?), which is super fast and easy to deploy on Docker but also Ruby, PHP etc to suit your taste/experience. The SPA approach means a frontend and a backend developed separately and unless you have FB scale issues and want to move as much work to the browser as possible, the only time I would choose SPA would be if I was most familiar with React/Angular/Vue/Javascript.
Next.js and Remix.run (even more so, in that you can deploy a Remix app with literally zero runtime JS) are examples of React frameworks that leverage a server runtime, to great effect. I've been building and improving websites / apps since 1998 and view Remix as a breath of fresh air, built from first principles.
I write in Go, use protocol buffers to define the api but will handle it via http(manual routing, not grpc gateway), event sourcing for the domain entities, db will by good old mariadb(i never found postgres interesting with its "exotic" types and lack of ui tools), front-end will be written in quasar which i will also use for mobile app(my first).
a lot of things can be done very easily and cheaply if one has the skill and time.