My team is a group of Swift developers that primarily works on an iPad app. We’re dipping our toes into the BFF “Backends for Frontends” pattern, which, combined with the modern world of containerization, makes Swift on the server make a lot of sense for us. It took a good bit of convincing for me that it was the right direction to go—even though I love Swift!—but Vapor has been a great success for us so far.
That said, I’ve not done a lot of server backend work aside from a stint in ASP.NET a few years back, so I certainly can’t say much intelligent about how it compares to other such frameworks; but, as someone who wants to stay in Swift as much as possible at the moment, it’s been great to develop in it on the backend, too.
I do backend work, but I don’t do it in Swift, because I don’t think it’s ready yet. For instance, the first steps toward async/await are only now being merged in. But I have a lot of history with Swift, it’s still my favorite language, and I look forward to a time when it could be a contending best choice for backend work.
“Swift on the server” is a top priority for the language team this year. Swift began at the level of front-end applications, but intends to grow its feature set and support base all the way to the domain of systems level languages like Rust, which is realistic too, maybe a few years from now. Backend work is considered to be a step on that path to systems work. The language team has a server working group and projects like SwiftNIO, Lambda runtime support, and this one. These are for creating a solid foundation and are not a complete path to smooth backend dev work, but add Vapor and you can cook up a nice API. Support for more Linux distros arrived this spring, though more are needed (I want Alpine, personally). And it may take some time for macOS-centrism to wash out of the language community.
In other words, keep your eye on it. If you’re interested, give it a try for applications or command line tools.
Is there anyone using swift on the backend here at all? If so, what are your thoughts on it as a whole? In addition to this project maybe?
My team is a group of Swift developers that primarily works on an iPad app. We’re dipping our toes into the BFF “Backends for Frontends” pattern, which, combined with the modern world of containerization, makes Swift on the server make a lot of sense for us. It took a good bit of convincing for me that it was the right direction to go—even though I love Swift!—but Vapor has been a great success for us so far.
That said, I’ve not done a lot of server backend work aside from a stint in ASP.NET a few years back, so I certainly can’t say much intelligent about how it compares to other such frameworks; but, as someone who wants to stay in Swift as much as possible at the moment, it’s been great to develop in it on the backend, too.
I do backend work, but I don’t do it in Swift, because I don’t think it’s ready yet. For instance, the first steps toward async/await are only now being merged in. But I have a lot of history with Swift, it’s still my favorite language, and I look forward to a time when it could be a contending best choice for backend work.
“Swift on the server” is a top priority for the language team this year. Swift began at the level of front-end applications, but intends to grow its feature set and support base all the way to the domain of systems level languages like Rust, which is realistic too, maybe a few years from now. Backend work is considered to be a step on that path to systems work. The language team has a server working group and projects like SwiftNIO, Lambda runtime support, and this one. These are for creating a solid foundation and are not a complete path to smooth backend dev work, but add Vapor and you can cook up a nice API. Support for more Linux distros arrived this spring, though more are needed (I want Alpine, personally). And it may take some time for macOS-centrism to wash out of the language community.
In other words, keep your eye on it. If you’re interested, give it a try for applications or command line tools.