@mhostetler That’s an awesome find! I had no idea such a tool existed, but at first glance it does seem promising.
I’m more than happy to collaborate on a Fly CDK. Let me know what’s your preferred channel of communication and we can kick off the initial conversations!
@lillian Thank you for the detailed response! I do find it a bit odd that it returned 422 for a duplicate app name, as the org I was testing against had only 2 apps, none of them named
test-app. Regardless, I’ll do some more testing today and report the findings, if any.
As for drawing inspiration from
flyctl, I found the repo after initially posting this thread and whilst it does offer great insight into how one might go about building their own, it wasn’t quite made for external use so some of the interfaces are more verbose than necessary. Of course, this doesn’t mean it can’t be used, only that one needs to pay greater attention when doing so.
To summarize, I find that going a similar route as @mhostetler does in his CDK, by writing it in TypeScript and then cross-compiling to a bunch of other platforms using
jsii would very quickly produce usable CDKs for a lot of different projects, which I believe would be highly beneficial to the community as a whole.
It would also be easier to maintain, as it’d be a singular code-base, as per Amazon’s claims:
The only, let’s call it concern, I have so far about Mike’s approach is that by wrapping
flyctl, you either bundle it in the CDK itself somehow, or it has to be installed as a dependency in the individual Dockerfiles of the projects, thus making Paketo builds less trivial for the languages that support it.
jsii also introduces a dependency on having a Node runtime installed.
L.E.: Looking through the AWS CDK in a bit more detail, as I am not familiar with it, it seems the CDK is more oriented towards an Infrastructure as Code approach, which is not my primary goal for the SDK. Whilst the SDK would be usable as an Infrastructure as Code engine, it wouldn’t be its primary purpose, but rather, to allow interacting with Fly in a programmatic manner.
Take the following example:
Suppose we have an application
test-app with 3 machines all deployed in
fra. These 3 machines work together as a cluster, communicating with eachother.
Let’s say we want this app to scale to zero when not in use, but because this is a cluster and the machines depend on eachother to achieve consistency, we can’t scale the machines independently but rather, all 3 must be turned off or on as a singular entity.
With the current
fly.toml configuration, this is, as far as I’m aware, not possible. The machines would be turned off one after the other, and when the proxy comes to turn them on, it will only do so for 1 of the machines. Whilst the other 2 could be coerced into turning on using the proxy, it’s not a great experience and could lead to errors / data loss.
Having an SDK would allow for custom setups where when 1 machine is booted up by the proxy, trough configuration or similar it could detect that it needs to turn on 2 other machines for the cluster to function, doing so with less delay and in a more deterministic manner, perhaps even queueing connections until the cluster is up, similar to how the proxy does it when it’s waiting for a machine to come online.
Similarly, when scaling to zero, we could leverage the SDK to turn off the other 2 machines in the cluster so that they don’t error out trying to communicate with the now turned off 3rd machine.
I hope the example above made sense.