Add deploy notion to Wasp files

[Martinsos]

Right now deployment of Wasp apps is pretty manual -> you generate code with wasp build and then you have to manually deploy different parts (frontend, backend), the procedure depending on which hosting provider you are deploying to.

Ideally, we want the experience to be the following:

1. In .wasp, you declaratively define your deployment, e.g.:

deployment production {
  client: {
    provider: netlify,
    netlify: { provider specific settings },
    ... // settings that are not specific per provider.
  },
  server: {
    provider: heroku,
    heroku: { provider specific settings },
    ... // settings that are not specific per provider.
  }
}

2. To deploy, you call wasp deploy, which then based on the declarative code in .wasp decides where and how to deploy the web app. It would actually call wasp build and then call commands needed to deploy the code. Ideally it would utilize Terraform for this, instead of us implementing logic that checks if something already exists, creating if it does not, and so on.

I tried coming up with Terraform script for deploying backend to Heroku, here is one version of it that works. I had to put it level above the whole project, otherwise it would complain about the checksum of the project (because it in the project itself, and probably modifying state.tf, which was modifying the checksum). But the main problem was that deploying was really slow -> the only support for deploying containers to Heroku was via their heroku.yml feature, where Heroku builds image on their own on their servers, which is super slow (7 minutes). Building image on our machine and then pushing it to Heroku container registry is not supported in Terraform Heroku provider nor will it be because it is not part of Heroku API.
Solution might be for us to implement this part, deploying image to Heroku, on our own - I guess Terraform must have some way of providing custom parts like this.

If we add support for couple of main hosting providers, like AWS, Netlify, GCP, Heroku, Render, Vercel, we have already covered a lot.

Btw Heroku is great to have because it is the only provider right now where you can run server + postgre DB completely for free. They now cost at least 10$ to run dynos + Postgres: https://help.heroku.com/RSBRUH58/removal-of-heroku-free-product-plans-faq

Terraform script (main.tf)

terraform {
  required_providers {
    heroku = {
      source = "heroku/heroku"
      version = "3.2.0"
    }
  }
}

provider "heroku" {
  # Configuration options
}

variable "test_app" {
  description = "Test app"
}

resource "heroku_app" "server" {
  name = var.test_app
  region = "us"
  stack = "container" # This means we are using Docker.
}

# Build code & release to the app
resource "heroku_build" "server" {
  app = heroku_app.server.name

  # NOTE: Assumes heroku.yml exists and it cointains build.docker instructions.

  source = {
    path = "out"
  }
  # TODO: Add `version` field?
}

resource "heroku_formation" "server" {
  app        = heroku_app.server.name
  type       = "web"
  quantity   = 1
  size       = "free"
  depends_on = [heroku_build.server]
}

output "server_url" {
  value = "https://${heroku_app.server.name}.herokuapp.com"
}

resource "heroku_addon" "postgres-db" {
  app  = heroku_app.server.name
  plan = "heroku-postgresql:hobby-dev"
}

# TODO: I had to move main.tf file one level above the `out` dir for stuff to work!
#   For this to work we will have to adjust output of generator, to generate one more
#   directory in out and then source goes into it -> `project` dir (do we name it after the app)?

[Martinsos]

@shayneczyzewski what you are building is not exactly this, as we are not doing the declarative part, but I still linked you to this issue since it is the closest we have to your work. When you are done, you can maybe comment on this issue and leave it open, but move it back to Backlog?

[Martinsos]

Or, feel free to open another, more relevant issue, and again put this one to Backlog and remove estimate from it.

[shayneczyzewski]

We recently merged in CLI support for deploying to Fly.io, but it would be nice if we can capture it in Wasp files still. This issue is to track adding deployment as a Wasp file notion.