In February 2018, at the try! Swift Tokyo conference, Apple announced SwiftNIO — a new cross-platform, asynchronous, event-driven networking framework for building servers and clients in Swift. SwiftNIO has the potential to provide all the low-level socket-handling and HTTP protocol support in Kitura, and hence could be a replacement for the current Kitura-net and BlueSocket libraries which underpin Kitura today. The Kitura team have been working on Kitura-NIO, a Kitura interface to SwiftNIO and we think now is a good time to release it for wider experimentation, testing and feedback.

Kitura-NIO has been designed to be API-compatible with current Kitura-net API, though the underlying implementation uses SwiftNIO. As a consequence, Kitura itself needs very few changes to run on top of Kitura-NIO. These changes are available in the new kitura-nio and kitura-2.4-nio branches. To use Kitura with Kitura-NIO, users just need to point to one of these branches from their application’s Package.swift and rebuild their Kitura application:

dependencies: [
   //other dependencies
   .package(url: "https://github.com/IBM-Swift/Kitura"), .branch("kitura-nio")),
]

These new branches will be updated and rebased regularly. If you have existing Kitura applications, Kitura-NIO is likely to provide all that your application needs, barring the FastCGI protocol implementation which we believe is not widely used. We urge you to test your applications’ functionality and performance and we will be happy to receive feedback — pull requests, bug reports, performance comparison reports, enhancement requests or anything else. We’re available on Slack or you can open an issue at the Kitura-NIO GitHub repository.

Kitura-NIO fully supports HTTP and HTTPS, both servers and clients. It also has IPv6 support. A NIO based implementation of Kitura-WebSocket is also on its way. Kitura-NIO is currently supported with Swift 4.1 and 4.2 on Ubuntu 14.04, Ubuntu 16.04 and macOS.

The major reason behind the decision to keep the API compatible with Kitura-net was API stability. We wanted Kitura users to experiment with Kitura-NIO, with zero code changes to their Kitura applications.

Performance analysis of Kitura-NIO is work-in-progress. We’ve identified a few bottlenecks and implemented some performance improvements already. Translating between the Kitura-net types and the SwiftNIO types does incur a cost. In future, we may want to eliminate this cost by exposing NIO types (or opaque wrappers of them) directly to Kitura users. This may require API changes, but it could be the path to better performance. However, we also know that Kitura users strongly value API stability, backward compatibility and ease of migration. So, we have an interesting trade-off problem at hand and we’d like to solve it in a way that best suits Kitura’s users. We would love to hear your opinion on this.

This blog post would be incomplete without thanking the SwiftNIO team — especially @johannesweiss and @Lukasaoz. The team has been approachable, extremely helpful and amazingly quick with our questions and bug reports!


Slack Icon


Github Icon

Join the discussion on Slack Learn more at kitura.io Star Kitura on GitHub

4 comments on"Introducing Kitura-NIO"

  1. I would vote on the side of breaking the API for the sake of improving speed. This is what new major releases are for.

  2. I think most Kitura (and by extension: server-side Swift) users understand that we’re early adopters. Given the small user base we currently have, and that standards and best practices are yet to emerge, an API overhaul is inevitable. As long as it’s not a yearly thing (and done for good reasons), I see no problem with it.

  3. It all comes down to the effort required on our side as well as the type of effort. If API change means replacing type x with type y it wouldn’t be a problem for us. If API change means having to re-architect our applications because of changes in the programming model it would be more of an issue. In other words “fix-it” like changes are ok – the more brain we have to use to adapt to the new API the more of an issue it would be.

Join The Discussion

Your email address will not be published. Required fields are marked *