use a resource that uses `api.url` allow origin in api's allow.origin

[tsuf239]

I tried this:

bring cloud;

class WebsiteServer {
  pub url: str;
  new (env: Map<str>) {
    // initializing some terraform and stuff....
    // doing some stuff with the env.
    this.url = "some terraform token";
  }
}

// creating a url that allows only the server origin
let api = new cloud.Api(corsOptions:{allowOrigin: server.url});

// the website server resource needs the api.url in its environment- since it's 
// essential to the initiation.
let server = new WebsiteServer({API_URL: api.url});

This happened:

I couldn't use a property url of a resource that wasn't initialized yet :(

I expected this:

to have a way to pass that

Is there a workaround?

No response

Anything else?

No response

Wing Version

0.66.5

Node.js Version

No response

Platform(s)

No response

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.

[tsuf239]

example in the playground

[Chriscbr]

example in the playground

It looks like there's a dependency cycle between the resources in the code (each is trying to depend on the other). Is it possible to make one of them add configuration later? e.g.

bring cloud;

class ImaginaryResource {
  pub url: str;
  env: MutMap<str>;
  new () {
    // initializing some terraform and stuff....
    // doing some stuff with the env.
    this.url = "some terraform token";
    this.env = MutMap<str>{};
  }
  pub addEnv(key: str, value: str) {
    this.env.set(key, value);
  }
}

// the imaginary resource needs the api.url in its environment- since it's 
// essential to the initiation.
let imaginary = new ImaginaryResource();

// creating a url that supports only the imaginary origin
let api = new cloud.Api(corsOptions:{allowOrigin: imaginary.url});

imaginary.addEnv("API_URL", api.url);

(some way to add CORS options to cloud.Api after it is constructed would also be ok I think)

[tsuf239]

also, this may work:

bring cloud;

class WebsiteServer {
  pub url: str;
  new (env: Map<str>) {
    // initializing some terraform and stuff....
    // doing some stuff with the env.
    this.url = "some terraform token";
  }
}
let var server: WebsiteServer? = nil;

// creating a url that allows only the server origin
let api = new cloud.Api(corsOptions:{allowOrigin: server?.url});

// the website server resource needs the api.url in its environment- since it's 
// essential to the initiation.
server = new WebsiteServer({API_URL: api.url});

playground here

[Chriscbr]

Recapping some of the options the team came up with offline:

• If the user's adds a custom domain with cloud.Domain as a third resource, then the URL will be known at compile time so it may be possible to avoid the dependency cycle. Pseudocode:

let domain = new cloud.Domain(url: "example.com");
let api = new cloud.Api(corsOptions:{allowOrigin: domain.url});
let server = new WebsiteServer({ API_URL: domain.url });

• The user can try to add some late-binding methods to their class so that API_URL does not need to be added in the constructor, like server.addEnvironment("API_URL", api.url) (see earlier comment)
• We can add some late-binding methods so that the CORS options can be added later in the preflight code, like api.addCorsOptions(allowOrigin: server.url). An addition to cloud.Api would be welcome!
• If the user is compiling the app for Terraform, they can pass a token which resolves at synthesis time to the correct value. Pseudocode:

let var serverUrl: str? = nil;

let api = new cloud.Api(corsOptions:{
  allowOrigin: cdktf.Lazy.string({ produce: () => { return serverUrl!; } }),
});

let server = new WebsiteServer({API_URL: api.url});
serverUrl = server.url;

It's possible we'll need to add support for something like this to the sim target, or more generally a cloud-agnostic token API to the language / standard library.