Add tab view in Playground/Tutorial to show either the simulator map view or lists of generated resources in the different clouds

[ShaiBer]

Feature Spec

Users are now better able to understand that Wing is not a toy when playing in the playground or doing a tutorial because they see in a clear way that we generate real cloud code

Use Cases

To show users we are not a toy. The simulator compiles so fast, users might not understand this is real cloud code

Implementation Notes

@eladb has thoughts on exactly what this should look like

Component

Playground, Tutorial

Community Notes

• Please vote by adding a 👍 reaction to the issue to help us prioritize.
• If you are interested to work on this issue, please leave a comment.

[ekeren]

Here is a sketch of how this could look like

[ShaiBer]

I love the direction, just missing a way to download the artifacts

[ekeren]

Added a way to download the artifacts

[ainvoner]

this site https://www.convertsimple.com/convert-json-to-hcl/ uses https://github.com/vgsantoniazzi/js-hcl-parser which I think enough for our needs

[ainvoner]

let's start by supporting the following:

1. design a new "target output" view by target type (we can use the design in the above comment or suggest a new one)
2. each step can define what to display in the target output section - simulator, aws/terraform, etc... there can be more than one target output. in case of multiple target outputs, we can use tabs (as in the above design).
3. start with implementing AWS/Terraform target output
4. compile to the simulator target is done automatically by the console
5. compile to any other targets is done by clicking a "Compile" button

example:

1. step 1 has a AWS/Terraform target output. The user in this step will see a view like in Add tab view in Playground/Tutorial to show either the simulator map view or lists of generated resources in the different clouds #2495 (comment)
2. step 2 has a Simulator target output. The user in this step will see the console (as it is now in lean.winglang.io)
3. final step has as array of target outputs [AWS/TF, Simulator]. The user will see each output view in a different tab (as shown above)

[ekeren]

@ainvoner , Maybe I should build something like this v1 Tour for my desired new flow?

[ainvoner]

@ainvoner , Maybe I should build something like this v1 Tour for my desired new flow?

sure. after finishing the implementing the relevant components we will follow your new flow.

[ekeren]

this site https://www.convertsimple.com/convert-json-to-hcl/ uses https://github.com/vgsantoniazzi/js-hcl-parser which I think enough for our needs

@skorfmann will help us with the "right" way to convert json->HCL

I showed him https://www.convertsimple.com/convert-json-to-hcl/ and he didn't approve

[polamoros]

AWS resource icons link

[skorfmann]

@skorfmann will help us with the "right" way to convert json->HCL
I showed him https://www.convertsimple.com/convert-json-to-hcl/ and he didn't approve

Yes, the syntax which is produced by these tools is neither idiomatic nor functional Terraform HCL config, but looks like some weird JSON like syntax (maybe HCL v1?). I think the challenge is, that the default use case is going from HCL to JSON for machine readable formats. The other way around is super rare. See this issue from the lib that’s being used in cdktf for hcl2json tasks tmccombs/hcl2json#2 - Plus, there's another issue in cdktf essentially requesting the same thing: hashicorp/terraform-cdk#225. TL;DR: HCL is a toolkit to build languages where Terraform HCL is a specific implementation of it. Converting from HCL -> JSON is straightforward, going reverse needs type information from the Terraform provider in some cases.

So, let's take a wing generated Lambda function as an example, the converted JSON from this tool looks like this:

"aws_lambda_function" "root_env0_cloudQueueAddConsumer3915c5ec_D9C8326B" {
  "//" "metadata" {
    "path" = "root/Default/env0/cloud.Queue-AddConsumer-3915c5ec/Default"

    "uniqueId" = "root_env0_cloudQueueAddConsumer3915c5ec_D9C8326B"
  }

  "environment" "variables" {
    "BUCKET_NAME_90d3f186" = "${aws_s3_bucket.root_env0_cloudBucket_DA9B7293.bucket}"

    "BUCKET_NAME_90d3f186_IS_PUBLIC" = "false"

    "WING_FUNCTION_NAME" = "cloud-Queue-AddConsumer-3915c5ec-c83da7e5"
  }

  "function_name" = "cloud-Queue-AddConsumer-3915c5ec-c83da7e5"

  "handler" = "index.handler"

  "publish" = true

  "role" = "${aws_iam_role.root_env0_cloudQueueAddConsumer3915c5ec_IamRole_54033248.arn}"

  "runtime" = "nodejs18.x"

  "s3_bucket" = "${aws_s3_bucket.root_Code_02F3C603.bucket}"

  "s3_key" = "${aws_s3_object.root_env0_cloudQueueAddConsumer3915c5ec_S3Object_F86765F2.key}"

  "timeout" = 30

  "vpc_config" = {
    "security_group_ids" = []

    "subnet_ids" = []
  }

vs the one you’d actually want to have

resource "aws_lambda_function" "root_env0_cloudQueueAddConsumer3915c5ec_D9C8326B" {
  function_name = "cloud-Queue-AddConsumer-3915c5ec-c83da7e5"
  handler       = "index.handler"
  runtime       = "nodejs18.x"
  timeout       = 30
  publish       = true

  role = aws_iam_role.root_env0_cloudQueueAddConsumer3915c5ec_IamRole_54033248.arn
  s3_bucket = aws_s3_bucket.root_Code_02F3C603.bucket
  s3_key = aws_s3_object.root_env0_cloudQueueAddConsumer3915c5ec_S3Object_F86765F2.key

  vpc_config {
    security_group_ids = []
    subnet_ids = []
  }

  environment {
    variables = {
      BUCKET_NAME_90d3f186 = aws_s3_bucket.root_env0_cloudBucket_DA9B7293.bucket
      BUCKET_NAME_90d3f186_IS_PUBLIC = "false"
      WING_FUNCTION_NAME = "cloud-Queue-AddConsumer-3915c5ec-c83da7e5"
    }
  }
}

As you can see, it’s not too far off in terms of general structure. (compare the tf resource as well https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/lambda_function)

One way could be to do some postprocessing. There are a few things that would need to be done:

• prepend resource
• get rid of " in keys
• no interpolation for references (e.g. the s3_bucket value)
• Drop // keys (comments in Terraform JSON)

The difficult part can be seen here:

  environment {
    variables = {
      BUCKET_NAME_90d3f186 = aws_s3_bucket.root_env0_cloudBucket_DA9B7293.bucket
      BUCKET_NAME_90d3f186_IS_PUBLIC = "false"
      WING_FUNCTION_NAME = "cloud-Queue-AddConsumer-3915c5ec-c83da7e5"
    }
  }

which looks like this in JSON

        "environment": {
          "variables": {
            "BUCKET_NAME_90d3f186": "${aws_s3_bucket.root_env0_cloudBucket_DA9B7293.bucket}",
            "BUCKET_NAME_90d3f186_IS_PUBLIC": "false",
            "WING_FUNCTION_NAME": "cloud-Queue-AddConsumer-3915c5ec-c83da7e5"
          }
        },

environment is a block, where variables is a map in tf hcl. So that’s impossible to know in a generic way by just looking at the JSON. Not sure how the converter guessed this, probably some heuristic. I think Terraform knows this by looking at the schema of the povider resource.

Another way could be, to actually build a dedicated TF JSON -> Terrform HCL converter. Here's an example to do this for Terraform tfvars (which is a pretty simple case).

Probably depends on how important this really is in the end.

[ekeren]

Done