Looks like he’s storing data in the server’s file system, but I see no mention of backups. Hopefully there’s more than one copy of the data somewhere (or it’s not critical data)!
"Nobody wants to backup, everybody wants to restore."
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.
Also, time to restore for many peoples solutions can be days or weeks (if something goes wrong). Oops if that means you’re down for weeks. For some businesses (SaaS), there is no point event trying to come back from that.
Indeed. In my experience, even if you don't use any other cloud service, do yourself a favour, and use S3 + Cloudfront (or equivalent) for static / uploaded files. Then, if and when you need to scale your web tier horizontally, you've solved what probably would have been your main blocker.
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).
Yeah, each of that requires extra cli/config/setup instead of just `import` libs. It's not about old or new, it's simple vs unnecessary deps (imply complexity).
React and Docker are both almost a decade old (both released in 2013). TypeScript is from 2012. Functional programming is very, very far from being a modern concept even if it's (maybe, finally?) getting a bit more attention.
So react's existed for almost half the time you've been using php. I think yhr distinction here is between tech that's new, and tech that's new for you
Old-school monolith architecture with not-so-boring technology. I went the same path for a project, but in hindsight I would chose popular, well maintained, not necessarily boring, technology and a cloud architecture for most use cases I can think of.
Disclaimer: I work for AWS in Professional Services. I specialize in “application modernization”. Basically that means a focus on serverless technology.
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.
I don't think he used a VPS; I think he just has a bare metal server (Linux).
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.
I think the use cases where you do not need to „know cloud“ are quite limited. Where does knowing the cloud start? When you use a transactional email provider? When you start using an auth. provider? When you integrate an external monitoring framework? When you use a cloud-based object or key-value storage? In my opinion, cloud integration is almost inevitable, but you might realize that a bit later when starting with a monolith.
IMHO a more interesting metric would be the ratio of successful startups using cloud technologies over the last years. I think the cloud is especially interesting to get a competitive advantage early on.
I beleive he said it's a boring B2B SaaS. And it's probably a niche market such that possibly (likely?) nobody reading HN would be involved in and be interested in his product.
I'd say this is quite biased, which is fine I guess, we all have our biases. Seems his choice of F# is set in stone, so you either go with Bolero or you have 1+1 languages in your stack.
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?
I would never choose a Google specific cross platform environment. A cross platform mobile environment constantly needs updating to stay consistent with the vendor’s platform. I wouldn’t trust Google to give that much attention to Flutter especially seeing they are moving away from it internally for iOS development.
You don't need to trust Google, but it certainly don't mean making general statements about what Google is doing. The article says nothing about discouraging Flutter use and given Flutter 3 came out this year, Google is still supporting and using it. Flutter has iOS UI replication of look and feel, which is what that article says Google is encouraging. Fuschia hasn't come out yet, but it still uses Dart and Flutter is used to create apps on it.
I'll take a bet, use and choose Flutter for a long time.
Google has a lot of trust in its infrastructure projects. You assert they don't therefore don't use it and you have many Google front-end platform projects that serve as counter examples to your assertion. Angular being the most popular
open source Google front-end project.
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.
I'm not interested in going in circles with this, but let's humor for fun some of what you've picked just this once. Original angular, superseded. NaCL, superseded. AppMaker, superceded. Swift for Tensorflow, are you saying Tensorflow was deprecated? Far as I know, Tensorflow is alive and well, so this choice is hazy.
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.
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.
When I googled how to create wasm apps, I got blazor. I come from a python background, so this is tempting to try our blazor for an interactive app, is it recommended? ( you don’t hear much about Microsoft tech here only Js or python)..
Given he gives no examples of "Flutter as well "suffers from many bugs and problems" and given one is bound to use third party libraries, maybe he refers to third party libraries he chose being buggy. It is too general and very unclear what this means. Dart/Flutter has been a wonderful experience by far when it comes to cross platform libraries.
First for context, I’m far from a Microsoft hater. I spent 22 years exclusively in the MS ecosystem. I love C# and even now I’m the go to person when it comes to implementing MS solutions on AWS for my department.
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.
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.
Is it really that much easier than just installing the same version of Postgres and running SQL queries to create the schema/seed the data? You’re not going to be using the same data in production and dev.
How do I install the same version of Postgres if my dev machine and production run different OSes? Should I use Debian/Ubuntu repositories, or should I use apt.postgresql.org? Should I trust a third-party company (EDB) to provide me with a sane Windows installer and not upsell me on services later? Do I really need the arcane "cluster" setup in Debian/Ubuntu packages? How do I run Postgres in WSL2 if I’m using the Debian/Ubuntu packages?
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.
SQL is a fairly common standard that’s been around for a few years.
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.
I wouldn’t go as far as say SQL is a standard. Yes there is standard SQL. But every database has its own dialect even for simple stuff like choosing a range of rows.
It’s been ages since I did bare metal/VM installs of databases and then it was MySQL. But installing the database is a one time thing. The challenge was and is always syncing schema changes and loading seed data.
That sounds like a more heavyweight[0], and much more cumbersome[1] version of using Docker.
[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.
If they are using UIKit, they aren’t using Flutter for cross platform development. They aren’t eating their own dog food.
> 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.
I am working on a new(again) project. I too will take the path of a monolith but later on i plan to add separate servers to handle chat, video(hosting and streaming), file hosting(ala cdn) and mailing(yes, i will write my own mailer).
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.
As someone who's working on something similar (one-man project), what I struggle the most is with the infra details.
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.
If you even don’t want to host the deployment environment, upload your docker images to https://fly.io. It brings your services online in minutes. Ship quickly today and once you have more time you can later run your docker images on your own infra w/o much or no changes at all to your images.
There’s a universe of tools that aim to provide simpler abstractions over infra as code these days. One of them is provided by my company, withcoherence.com. While many of the advantages such as automated per branch ephemeral environments, accrue to teams, solo builders in some ways get more leverage from infra abstractions that let them focus on their own application.
Other than already mentioned backups I see no mention of:
* 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
First of all there's literally a paragraph called Infrastructure. Then one of the arguments is how cheap it is.
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.
Agreed that "SPA by default" is often a mistake. But (slight tangent / refinement), React != SPA.
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.
73 comments
[ 0.21 ms ] story [ 141 ms ] threadAt 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).
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?).
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://9to5google.com/2021/10/10/google-ios-apps-native/
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?
https://killedbygoogle.com/
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
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.
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.
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.
* 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.