@winglibs/postgres enhancements to support RDS, RDS Proxy and expose connection string for consumption outside wing

[ekeren]

Use Case

You can now use @winglibs/postgress for your RDS deployments on AWS, this release also include:

• Connecting any tyepscript/javascript client with the postgress deployment using the public connectionString value
• Using RDS Proxy

This is a breaking change, while previous versions of tf-aws where creating a neon based DB, from now on the default if RDS, in order to override this, please use platform parameters

Proposed Solution

No response

Implementation Notes

No response

Component

Libraries

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.
• If this issue is labeled needs-discussion, it means the spec has not been finalized yet. Please reach out on the #dev channel in the Wing Slack.

[MarkMcCulloh]

What about an @winglibs/rds instead? RDS is nice but a lot of wing usage is serverless and AWS's serverless postgres offering is pretty bad. Not to mention the inclusion of a RDS Proxy abstraction will likely make this useful in AWS only.

[ekeren]

What about an @winglibs/rds instead? RDS is nice but a lot of wing usage is serverless and AWS's serverless postgres offering is pretty bad. Not to mention the inclusion of a RDS Proxy abstraction will likely make this useful in AWS only.

I don't have any strong opinion here, questions/issues:

1. I feels like bring sql; is the right namespace for all these models

   new sql.Postgress(); 
   new sql.MySql();
   new sql.SqlLite();

2. Isn't RDS proxy a non functional concern?

3. We will probably need to support both RDS and Aurora

[eladb]

I think this should be bring postgres, because that's the intent of the developer. RDS is a specific implementation of postgres on AWS and theoretically, any Postgres installation should work if that's the surface area we expose.

I don't think we should put all of the SQL databases in the same library...

[MarkMcCulloh]

specific implementation

We have several winglibs that are intentionally (and named with) specific implementations even though they could technically fit as part of a broader abstraction

[eladb]

I think the best way to think about this is what is the surface area we want to expose to the application, and to my understanding the surface area is Postgress (the app uses the postgress client).

So from a developer standpoint, they are saying "I want a postgress database". The platform team can then decide how this postgres database is going to be deployed, and RDS is one of the options.

[Chriscbr]

Are there RDS-specific APIs that the user would want to be able to use in preflight or inflight code? Here's a list I found on AWS's website: https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_Operations.html

If there are any in this list that seem useful for application code, and there are ways to model them in the simulator, then a separate winglib makes more sense. If not, then I'd lean towards packaging it as part of the postgres winglib.

In the latter case, maybe the postgres winglib could add a platform parameter for tf-aws that lets you decide whether you want the implementation to use RDS or Neon.

[ekeren]

Are there RDS-specific APIs that the user would want to be able to use in preflight or inflight code? Here's a list I found on AWS's website: https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_Operations.html

I've asked the designated customer, and they said that they don't use any non postgress API

[ekeren]

In the latter case, maybe the postgres winglib could add a platform parameter for tf-aws that lets you decide whether you want the implementation to use RDS or Neon.

@Chriscbr, this is quite similar to my original proposal beside the fact that I think that RDS should be the default.

[Chriscbr]

Sounds good to me 👍 PRs welcome

[staycoolcall911]

Completed in https://github.com/winglang/winglibs/pull/219