This is great, and will be keen to have a look at helping for Linux support you have planned. ECS is one of the better products AWS has produced IMO. It has its warts, but it has made very intentional trade offs between simplicity and control/flexibility, and for a very large amount of use cases, I think they have made some really good choices. Thanks for sharing!
Neat, but this feels to me like buying a single-use kitchen gadget. Yes, the console does not have everything neatly together like this, but it can manage everything across all AWS services.
Having to deal with a separate (electron) app for every AWS service would be a nightmare.
The cross cutting concerns with ECS + ALB + ASGs + Capacity providers + target groups + EC2 instances + launch templates means that ECS is somewhat central to the larger context of your hosted system. I really like ECS, but AWS have done a poor job of presenting all the linked parts stemming from ECS that this app actually tries to solve. Yes, it wraps several services to achieve this because it has to, but ECS is central enough that having an app like this to show things in a more contextualized way I think can be extremely useful.
And I too intended to build one to server my specific ops needs and satisfy my taste for what information should be presented instead of how AWS organizes thing.
Tried it out for a few mins and it does what advertised. I think Electron is perfectly fine for what this app does: Managing ECS. It's not an all-in-one platform the same way VSCode is, so bloating isn't really an issue. On my M2 MacBook pro 64GB, it's sitting at 30.5 Mb of memory usage. JetBrains' toolbox app (Written using Java) is sitting at 505.1Mb and this app arguably does more than that one, if not an equal amount. The wallpaper process is taking up 29.9Mb of memory, so this app amounts to just another wallpaper worth of memory which is nothing.
However, for any app that aims to be an "all-in-one" desktop GUI replacement for the aws console, which may need extensions, a native framework would be the way to go over electron.
One piece of feedback I have is to just have a selection menu for models from providers rather than asking the user to input text, as well as an option for effort level if available.
Tauri uses the webview provided by the OS instead of bundling a full Chrome installation. The downside is that it may not look the same on all platforms.
go build one for free and then lecture others, besides i think his UI looks wonderful, props to the creator of this ECS app for sharing it with the world
Having to deal with a separate (electron) app for every AWS service would be a nightmare.
There was a similar undertaking to create something like k9s for ECS called E1S:
https://github.com/keidarcy/e1s
And I too intended to build one to server my specific ops needs and satisfy my taste for what information should be presented instead of how AWS organizes thing.
"Mercek" means lens in Turkish, and similarly it comes from the Turkish word "mercimek" (which means lentil).
I literally cannot run anymore without slowing everything down.
This is something which other software makers need to start considering.
There's actually limited RAM now on machines.
Codex and Claude Desktop both are gigantic memory hogs. And they leak memory all the time, but they provide value which is quite high.
Add in a couple of editors and the GitHub app. And then the actual browsers. And it actually stops me from downloading any more electron apps.
Could this be made into a native application?
However, for any app that aims to be an "all-in-one" desktop GUI replacement for the aws console, which may need extensions, a native framework would be the way to go over electron.
One piece of feedback I have is to just have a selection menu for models from providers rather than asking the user to input text, as well as an option for effort level if available.
Tauri uses the webview provided by the OS instead of bundling a full Chrome installation. The downside is that it may not look the same on all platforms.