In other words, has anyone does this before? What has your experience been like?
I didn't know about this. But this looks good.
Only benefit I can think of is for Swift Developers. They can now code their Apps full scale. The community will obviously grow as the time passes.
The best part is that commonly the Mobile apps needed backend but very less fraction of it (if the project is completely Mobile App based) and for server they needed to head to some other server-side language; now they can go full scale with one language.
Though in aspect of available frameworks, plugins, tutorials; node server has a lead for now.
I agree with Pankaj Patel. Server-side swift also seems to have a slight performance advantage according to this article.
The benefits are the same of many others languages, and as Pankaj Patel says, the most benefits are for Swift developers.
Swift are a pretty good language for developing any types of applications, but right now is not mature like Go, Node.js, Elixir or even Ruby.
When you're developing a server-side application for production, you need trust and stability from your language and dependencies, of course innovation are very welcomed, but its a big deal when you're on business, startups have more flexibility to change in this point.
But, well, talking about performance. Benchmarks over web in many times are not a good comparative to choose a language, because benchmarks focus on minimal cases, not productions cases, there's no integrations or business rules applied, its just rendering a json or something like this. See the article from Eran Hammer about it.
When you're using a language built around a compiled language of course compiled languages have more performance than a interpreted language.
Swift have a really nice opportunity to grow and be a awesome backend tool, but right now IMHO are not ready.
I have been working in nodejs development since last year and gave server side swift a try just to learn the basics since server side provided significant performance advantage than nodejs according to an article I read on medium.
However lack of wide module and support similar to npm in nodejs might be an issue. Secondly there were certain swift frameworks like perfect,vapor and kitura written for the same purpose. Out of them perfect was little easy to set up.
I felt that might server side might enhance backend capabilities but there was not a wide support for its implementation so went back to nodejs since using same language(js) in backend and frontend does seem much easier.
Marcos Bérgamo
Backend Developer
Lorefnon
Open Web Enthusiast
I have been lately experimenting with server side development with Swift, primarily to explore the potential of near native performance in a high level language (I don't consider Go high level and find it too spartan to my taste in terms of language level features) as well as a strongly typed system with built in support for null safety. Lack of garbage collection and ARC is uniquely interesting in itself.
The primary problem at this point is the anaemic ecosystem around web development. While the ecosystem around Vapor etc. is rapidly growing, it is far from what you would expect from Node ecosystem or Rails.
Vapor (the only framework I have used so far) offers a really nice type-safe API that caters to most common use cases. However it is still not production ready and the issue tracker has many open issues (some filed by myself). Situation with most popular libraries is the same. The language itself keeps introducing low level changes between iterations - and many libraries have platform specific issues (eg. things that compile in OS X don't in linux etc.)
A sophisticated ORM like ActiveRecord does not exist at the moment but surprisingly GraphQL library is pretty good (I will blog about this in near future).
The prevalent concurrency model is GCD (Managed thread-pool) which is battle-tested in IOS/OS X applications. But there are also parallel efforts to incorporate Go style concurrency and some frameworks claim it to be a much better model for web servers. It is likely one of these approaches will emerge as a more popular solution but it is not obvious at the moment.
Build times are also not ideal and because of the way Swift package manager currently works, a fresh build of a vapor project builds all the dependencies too which can lead to fairly large compilation time (> 5-6 minutes for trivial projects).
Also, perhaps the only decent Swift IDE at the moment is Xcode, and Xcode integration with Swift Package Manager is work in progress. In general Xcode lags behind sophisticated IDEs like IntelliJ in terms of features. While syntactical error reporting, auto-completion etc. work quite well, automated complex refactorings etc. are a pipedream at the moment. Things like jump to definition across modules (managed by SPM) often inexplicably fail. There are on-going attempts to make editor agnostic language server (SourceKitten) but I have not been able to get them to work with my favorite editor Emacs.
Also very surprisingly getting the built in REPL or XCode playgrouds to work with third party packages installed through Swift Package Manager is a PITA.
So all in all, Swift is a really elegant language (not without few eccentricities though) with a strong emphasis on Type-safety and high-level programming while at the same time being very approachable to new comers. Playgrounds are a really nice concept, language level error reporting and feedback is great.
But the ecosystem around web development is not yet ready for primetime. If you are building hobby projects or small micro-services it is a great avenue to explore. But if you are thinking about a large scale commercial application - hold on, and consider better supported alternatives at the moment or be prepared to seriously invest time and effort in evolving the foundational ecosystem itself.