jsii
aws-cdk-rfcs
Our great sponsors
jsii | aws-cdk-rfcs | |
---|---|---|
33 | 15 | |
2,553 | 512 | |
1.5% | 0.4% | |
9.4 | 8.7 | |
10 days ago | 26 days ago | |
TypeScript | JavaScript | |
Apache License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
jsii
-
The Stainless SDK Generator
What about jsii? The technology behind AWS sdks: https://aws.github.io/jsii/
Is Stainless similar, different?
-
AWS Makes Cloud Formation Stack Creation Up to 40% Faster
The libraries for other supported languages of CDK are built as wrappers for underlying JS or maybe TS code via https://github.com/aws/jsii
So all the core CDK code is written first in JS/TS and then stubs for the other languages are added
Unfortunately this is often done without consideration for how the other supported langs actually work, and artefacts of e.g. JS lack of support for kwargs leak through
This is why e.g. the typing in CDK Python is completely broken - pretty much uniformly the concrete types like "Resource" don't implement their corresponding interface like "IResource" (to a type checker)
(There are many other typing niggles like this but that's the most egregious and pervasive one)
At the end of the day, having to explicitly cast concrete types as their interface to satisfy type checker is a minor annoyance, albeit a stupid one that could have been avoided with more care in the core library.
I could live with that, but I encountered so many bugs and issues trying to use CDK on current project that it's now much clearer to me why every company I worked at previously was using Terraform.
Pretty sure some of those issues are ultimately CloudFormation ones. The cumbersome CF > CDK JS > CDK Python stack is great for obfuscating errors and making debugging hard or impossible though.
Pulumi do something similar, albeit with Go as the core language and Terraform underneath. From what I've seen with a little use they have a much more successful result though, Pulumi Python was not a complete mess, and deploys faster and more reliable with better error feedback. I guess they just took more care to get it right.
-
Infrastructure Manager: Provision Google Cloud Resources with Terraform
Every version of the CDK uses an interop layer and runs on top of the Typescript version
https://github.com/aws/jsii
And as far as TF supports services before CFT. Guess which is easier for an AWS employee to do - getting the CF service team to support a new service or just contribute to Terraform’s open source project?
I know of at least one service where the service team introduced the needed APIs and then an employee of AWS wrote the TF provider and contributed to the project before AWS’s own internal team added it to CFT.
Source: former AWS ProServe employee
- JSii allows code in any language to naturally interact with JavaScript classes
-
Cloud, why so difficult? 🤷♀️
To "meet developers where they are" is a beautiful tenet of AWS, and of the CDK, and inspired us to create awesome technology such as JSII and constructs.
-
Automating AWS API gateways v1 REST
Yeah both CDKTF and Pulumi piggyback on JSII, a class translator that supports the languages you've mentioned, which was used as a building base for CDK.
-
New open-source programming language for DevOps engineers by the creator of the CDK
The reason we chose to start with compilation to JavaScript and not some other popular cloud language is because JavaScript is currently one of the most used ones, and in addition, we are using JSII to write our SDK in Typescript and then export it for consumption in other languages, such as Go, Python, Java and others.
- Write SDK “base” in Rust, wrap in other languages?
-
CDKTF Frequently Asked Questions
The CDKTF CLI is implemented in TypeScript. Providers and resources are implemented in TypeScript as well. jsii is used to compile the providers and resources to the supported languages.
- 10 things about AWS CDK
aws-cdk-rfcs
-
What's Next for CDK? 👀
This was the most voted RFC.
-
Build AWS Serverless Scheduled Tasks with Amazon EventBridge and CDK
The scheduler is a refined and improved version of the older rules mechanism. So, why would you use the older rule mechanism for scheduled tasks? I don’t see any reason other than the better CDK constructs support (which is only temporary, see this PR).
-
Building a Robust Serverless Messaging Service with Amazon EventBridge Pipes and CDK
CDK released the L1 construct for Pipes in v2.55 back in December 2022. Unfortunately, the L2 construct is still in progress, so we will have to manually specify most of the CloudFormation template but bear with me, it won’t be too painful. The community is working on an L2 construct; you can find the issue on GitHub here.
-
Regain control over orphaned resources with CDK
The experimental cdk feature is described here. The rfc is still open so you might be able to track or influence how it will stabilize.
-
Serverless Weather Reporting with AWS Step Functions and CDK
More info on L1 vs L2 constructs here. I plan to keep an eye on this open RFC.
- Various cdk assets and implications of deleting them
-
Moving to CDK pipelines from not using pipelines
You could hardcode the stack names. But this is one of the biggest limitations CDK still has: no easy way yet to refactor names like this. There's an open RFC, but it isn't moving much.
-
Create Serverless Data Pipeline Using AWS CDK (Python)
It is not very convenient to delete some resources manually and there are several discussions with AWS developers to fix it.
-
Testing the Async Cloud with AWS CDK
It's worth mentioning that AWS CDK already has an RFC for integration testing so we might end up with something even better. In the meantime, if you are serious about integration testing, time to give AWS CDK and Provider Framework a look!
-
Ping Me! (Intro: IaC and Prep Work)
One apparent limitation of the CDK is that, at least for the nonce, it can only be used with AWS (there are two notable projects in the work right now that will greatly expand CDK's reach: cdk8s and cdktf). With Terraform you can use choose from a plethora of providers. Hell, I was able to set up my home network running on Unifi Dream Machine using Terraform. How cool is that?!
What are some alternatives?
Pulumi - Pulumi - Infrastructure as Code in any programming language. Build infrastructure intuitively on any cloud using familiar languages 🚀
Ansible - Ansible is a radically simple IT automation platform that makes your applications and systems easier to deploy and maintain. Automate everything from code deployment to network configuration to cloud management, in a language that approaches plain English, using SSH, with no agents to install on remote systems. https://docs.ansible.com.
projen - Rapidly build modern applications with advanced configuration management
websocat - Command-line client for WebSockets, like netcat (or curl) for ws:// with advanced socat-like functions
awesome-projen - P6M7G8's Awesome Projen
Cypress - Fast, easy and reliable testing for anything that runs in a browser.
middy - 🛵 The stylish Node.js middleware engine for AWS Lambda 🛵
cdk-eventbridge-socket - CDK construct that creates a WebSocket endpoint for you for any EventBridge rule you are interested in. (Built for debugging + testing )
aws-cdk - The AWS Cloud Development Kit is a framework for defining cloud infrastructure in code
aws-sdk-js-v3 - Modularized AWS SDK for JavaScript.
aws-testing-library - Chai (https://chaijs.com) and Jest (https://jestjs.io/) assertions for testing services built with aws