Why not netlify/vercel?

• Blog Post Archived
• Notes
  • https://twitter.com/JoshuaLelon/status/1318569847580753920?s=20
  • The question of owned vs a service comes down to how far into the future you see yourself a given idea. The more permanent, the more confidence you have in the long term, the more you should own the resources.
  • Intro
    • Explaining how awesome Netlify and Vercel are. But it's now owned.
  • Terraform/AWS
    • Infrastructure As Code
      • AWS provider built out. Netlify or Vercel... not so much
    • AWS cloud credit
    • Own the resources
  • Flexibility vs Convenience
    • How to think about this tradeoff? Confidence in the longevity of a project
    • Want to prototype ideas quickly - how to spin up as soon as possible
    • Building my own way to do this in the Terraform/AWS space
    • Could reference Create Vargas App
• Content {{word-count}}
  • Netlify offers one of the fastest ways for web developers to deploy their new web applications. Vercel is competing in the same space, while also integrating particularly well with their open source server-side rendering web framework Next.
  • Both products are extremely easy to use. You simply create a site on their dashboard, connect your GitHub repository with the directions to build your frontend, and now on every merge to master your site will be automatically deployed to the chosen domain. They also both support buying custom domains so that you don't have the .netlify.app or .vercel.app on your site's URL.
  • So naturally, in this article I want to talk about why I don't plan to use either for the foreseeable future.
  • The Alternative: Terraform/AWS
  • After years of hiding behind a veil of black magic, dev-ops and infrastructure is finally becoming more approachable through a new paradigm known as Infrastructure as Code. The premise is that instead of configuring hardware resources in separate UIs and dashboards, they could be managed in git with the rest of the application software.
  • Let's explore what deploying on Netlify or Vercel looks like today. Typically there would be a package.json file at the repository root with a script specifying how to build the app. Then in Netlify, the deploy settings would need to be updated to reflect this change.
  • 
  • 
  • Now for whatever reason, let's say you want to update the command to build the site or where it gets published. Which do you update first? Merging the new package.json script first will cause the Netlify build to fail due to it being configured the old way. Updating the Netlify UI first will cause it's deploy to fail due to the code it's reading not supporting the new script yet.
  • This is the power of Infrastructure as Code. You ideally want this change to happen at the same time. As part of one commit, the new script should be created and the deploy instructions should be updated.