I’m struggling with this article a little bit. I’ve admittedly been mostly down in the weeds doing high-performance edge computing for half a decade but did a lot of web and mobile work in the past. I’ve always been a big fan of “keep it simple” until you’ve proven that “simple” won’t work for what you’re trying to do. The moment they said, in the v0 architecture, that they had a Netlify “serverless” application connecting to a DigitalOcean PostgresQL instance, red flags were going off in my head. Having half your app on one cloud provider and half on another… thoroughly violating the KISS principle.
Our first batch of potential (enterprise) customers expressed a need to deploy the app behind their firewall.
And then looking at this requirement and choosing to build it out using S3 (Amazon) storage with Docker images deployed to Docker? Is that what “behind their firewall” means?
We moved the application off of Netlify simplified our hosting situation. On the downside, in the move to Digital Ocean we lost our branch deploy strategy. We propped up a staging server but it wasn’t the same as an automated branch deploy.
This seems like something that would take a couple of hours to set up with (depending on your choice of poison) a GitHub Action or Jenkins or a Gitlab whatever-they-call it and nginx fronting it. Based on the other architectures I can only assume that the auto-branch-deploy-to-subdomain was still hitting the production database so there wasn’t really anything else that would have needed to be stood up beyond another copy of the docker container running on another port and telling nginx to point to it.
Onward to v2…
Having Teams meant having a new permission system, authentication system, and invitation system.
I’m a big fan of YAGNI (you ain’t gonna need it) but… based on what this product is I’m having a really hard time imagining designing the initial database schema thinking “oh, we won’t need to have an extra Team table and map Users to Teams for authentication”.
Our Docker deploys were taking 20 minutes to build the image + 10 minutes switch over to the new image and stand up the environment.
What the heck was going on with that? For extra paranoid we rebuild our relatively chonky C++ app from scratch on our build server for every build and it takes significantly less time than that to build the whole thing, bundle it up in a deb, push it to OpenRepo, and pull the new version down onto our edge devices.
This refactor was a lot of work (and re-work) but thanks to two full-time hires we were ready to begin our Private Beta by the end of the summer.
Anyway, I’m tired and this isn’t helping the spirits. This post feels like it’s rehashing a lot of how all of these new “it’ll help you go faster” services can really slow things down by making everything too complex while simultaneously locking you into a specific platform. I’m sure they started the journey on Netlify thinking “Netlify will handle our infrastructure so we can focus on building our product” and then tripped over and over trying out different services that made the same promises instead of just… doing the slightly harder-up-front simple thing.
Yeah that first architecture diagram mixing Netlify with DigitalOcean just looked like self imposed pain. At least save effort by either using a DBaaS from Netlify or putting the Nuxt thing in DigitalOcean so it’s all in the same place.
Not using Rails because “DHH was being a dick” is really interesting because I can see both why that’s a silly basis for a decision and why I can’t blame anyone either.
That said, I don’t think there’d be so much churn in their architecture if they used Rails from the start. Especially if the business is the size that manually setting up new customers was the SOP. Rails is great for that. But I think Node has a Rails-like thing, too. Point is, batteries included frameworks exist for a reason.
[note: the author and I have similar handles. And we are both Dave. I’m not him tho just in case you read quickly ]
I’m struggling with this article a little bit. I’ve admittedly been mostly down in the weeds doing high-performance edge computing for half a decade but did a lot of web and mobile work in the past. I’ve always been a big fan of “keep it simple” until you’ve proven that “simple” won’t work for what you’re trying to do. The moment they said, in the v0 architecture, that they had a Netlify “serverless” application connecting to a DigitalOcean PostgresQL instance, red flags were going off in my head. Having half your app on one cloud provider and half on another… thoroughly violating the KISS principle.
And then looking at this requirement and choosing to build it out using S3 (Amazon) storage with Docker images deployed to Docker? Is that what “behind their firewall” means?
This seems like something that would take a couple of hours to set up with (depending on your choice of poison) a GitHub Action or Jenkins or a Gitlab whatever-they-call it and nginx fronting it. Based on the other architectures I can only assume that the auto-branch-deploy-to-subdomain was still hitting the production database so there wasn’t really anything else that would have needed to be stood up beyond another copy of the docker container running on another port and telling nginx to point to it.
Onward to v2…
I’m a big fan of YAGNI (you ain’t gonna need it) but… based on what this product is I’m having a really hard time imagining designing the initial database schema thinking “oh, we won’t need to have an extra Team table and map Users to Teams for authentication”.
What the heck was going on with that? For extra paranoid we rebuild our relatively chonky C++ app from scratch on our build server for every build and it takes significantly less time than that to build the whole thing, bundle it up in a deb, push it to OpenRepo, and pull the new version down onto our edge devices.
Anyway, I’m tired and this isn’t helping the spirits. This post feels like it’s rehashing a lot of how all of these new “it’ll help you go faster” services can really slow things down by making everything too complex while simultaneously locking you into a specific platform. I’m sure they started the journey on Netlify thinking “Netlify will handle our infrastructure so we can focus on building our product” and then tripped over and over trying out different services that made the same promises instead of just… doing the slightly harder-up-front simple thing.
Yeah that first architecture diagram mixing Netlify with DigitalOcean just looked like self imposed pain. At least save effort by either using a DBaaS from Netlify or putting the Nuxt thing in DigitalOcean so it’s all in the same place.
Not using Rails because “DHH was being a dick” is really interesting because I can see both why that’s a silly basis for a decision and why I can’t blame anyone either.
That said, I don’t think there’d be so much churn in their architecture if they used Rails from the start. Especially if the business is the size that manually setting up new customers was the SOP. Rails is great for that. But I think Node has a Rails-like thing, too. Point is, batteries included frameworks exist for a reason.
[note: the author and I have similar handles. And we are both Dave. I’m not him tho just in case you read quickly ]
Going to be honest and say I have had to click through to your bio before to confirm that you are not Dave Rupert.