Open Chriscbr opened 1 year ago
Hi,
This issue hasn't seen activity in 60 days. Therefore, we are marking this issue as stale for now. It will be closed after 7 days. Feel free to re-open this issue when there's an update or relevant information to be added. Thanks!
@Chriscbr should this be in the cloud namespace or an std namespace ?
No strong preference from me
The console could also have a dedicated place for these outputs.
Let's get this implemented.
@ainvoner @skyrpex
I think these outputs should be included in the preview environment comment.
For example, this could be the way we show the endpoints an app is exposing.
@staycoolcall911 can we prioritize
@eladb yes of course. Updated to p1. We should soon find some time to go over all our p1s
what's the naming gonna be? Personally I like Output
, Endpoint
implies some functionality aspect to me.
Output
is more general and may have more requirements. We discussed briefly how we can start with Endpoint
and perhaps expand that to Output
in the future. However @eladb, @Chriscbr might want to weigh in as well.
Output
is more general and may have more requirements.
Could you elaborate on the potential requirements which popped up during your discussions?
It wasn't a long discussion. It's just the general idea that a Wing program's Output
is broader than just an endpoint. It could be a tarball or any other artifact, for example.
BTW, the name endpoint is also not great and is ambiguous with cloud.Api
endpoints, so maybe we can find a better name for this which is not Output
or Endpoint
.
Let's go with cloud.Endpoint
for now. I think there's value in higher level modeling. We can always add cloud.Output
later as a more general purpose thing.
Our use case right now is to model the idea of an endpoint and explicitly expose these endpoints in Wing Cloud.
So let's go with cloud.Endpoint
.
The API is straightforward:
new cloud.Endpoint(url);
No?
Renamed title to cloud.Endpoint
BTW, I think that when we compile to tf-aws, a Terraform output should be defined implicitly.
The API is straightforward:
new cloud.Endpoint(url);
Since it's the only wing native way of creating outputs then, what's stopping users from just using it as output? Is there any functionality attached to it?
Let's keep this issue to track cloud.Output
and split cloud.Endpoint
into a separate issue.
An endpoint is more than just an output. Our use case is to be able to show endpoints in the console, expose them from preview environments and from local dev machines, maybe bind them to domains, etc.
So they need to be explicitly modeled.
I am not against also introducing cloud.Output (now or later) and define an output for all endpoints, but it's not required for the endpoint use case.
Hi,
This issue hasn't seen activity in 90 days. Therefore, we are marking this issue as stale for now. It will be closed after 7 days. Feel free to re-open this issue when there's an update or relevant information to be added. Thanks!
@eladcon I'm taking you off the issue because I know it's not on your plans anymore. This issue is up for grabs
Hi,
This issue hasn't seen activity in 90 days. Therefore, we are marking this issue as stale for now. It will be closed after 7 days. Feel free to re-open this issue when there's an update or relevant information to be added. Thanks!
Feature Spec
cloud.Output
is a preflight class allows you to export structured data about your app. For terraform this compiles to a Terraform output value, and for AWS CDK this compiles to a CloudFormation output value.Example:
When compile this to terraform and apply the terraform configuration, you'll see the output listed:
Use Cases
Sharing/reference values between multiple (Terraform/Cloudformation/etc.) apps.
Exposing information about your app to the command line.
Implementation Notes
No response
Component
SDK
Community Notes