What are the pain points of deploying Swift on Server applications?

Pretty much same issues for embedded. I have one board where ideally there’s just a 32-bit ARM and only a single Swift binary; static linking with no Foundation makes sense for this. The other is a Pi Compute Module, with a few different binaries (some of which need Foundation) and which have many dependencies in common, so shared libraries for all common dependencies would be preferred. I suppose the firmware build could identify the common dependencies and rewrite Package.swift.

it costs about $5.50 per month after factoring in savings plans, and including disk storage, but not including Elastic IPv4 addresses. however it also has first-party integration with S3 and other AWS services, so this makes managing the security rules a lot easier. the 1TB of free Cloudfront data transfer to the internet is also nice.

right, this brings us back to the “plugin” architecture we were discussing earlier in the thread. a lot of things you want to run in the cloud are not going to fit into neat increments of 500MB, 1GB, 2GB, 4GB RAM, etc., and don’t need dedicated IP addresses. so there’s a lot of value in being able to co-habit multiple apps on one host.

if you’re using the monolith deployment model, you’ve got to compile a new executable “image” containing all the apps you want to run on each node, for every single update.

2 Likes

for what it’s worth, i am actually using the monolith deployment model pretty much everywhere, for the same reason i suspect so many other people are.

i hate it, because most of my hosts run a mixture of free and proprietary “apps”, and the vast majority of the updates i push are updates to the open source components.

because i’m deploying monoliths, i have to recompile the free code along with the proprietary code, which means i have to rebuild a lot of executables in the “secret hanger” instead of just pulling artifacts from open distribution channels.

I think for non-indie, actual business focused projects, the SLA aspect is relevant here. You can get SLA's for common tech's but not for Swift, and that's a major pain point, to bring the thread back to the original context.
And the worst part is that it isn't just about the Swift stuff, it even replicates things we do have system level contracts for, like OpenSSL or libcurl. That is viable for Apple itself, but for almost no one else.
Language stability, ABI, all play into this. I don't see those things being addressed anytime soon. IBM was some hope here, but that didn't work out ...

1 Like

Right now the lack of GCP and Azure SDKs is very painful.

This list covers our biggest pain points quite well. (Although support for pre-built dependencies on Linux would lessen the pain of not supporting shallow git clones!)

Additionally, while sourcekit-lsp has come a long way, it is still frustratingly unstable. At least when used in combination with VSCode running in a Linux-based devcontainer, it is slow when it is working but often becomes unresponsive without crashing, necessitating a manual window re-load in VSCode to get going again.

2 Likes

Full GCP SDK - GitHub - vapor-community/google-cloud-kit
There's a Azure PoC that covers signing - GitHub - brokenhandsio/swift-azure-sdk