SwiftNIO is fundamentally a low-level tool for building high-performance networking applications in Swift. It particularly targets those use-cases where using a "thread-per-connection" model of concurrency is inefficient or untenable. This is a common limitation when building servers that use a large number of relatively low-utilization connections, such as HTTP servers. To achieve its goals SwiftNIO extensively uses "non-blocking I/O": hence the name! Non-blocking I/O differs from the more common blocking I/O model because the application does not wait for data to be sent to or received from the network: instead, SwiftNIO asks for the kernel to notify it when I/O operations can be performed without waiting.The core of this communication between an app and the cloud happens with
EventLoop, which is an open stream of I/O between the cloud and an app. Apple says SwiftNIO applications will have few event loops, “usually only one or two per CPU core the application wants to use.” Those I/O loops can also be corralled into groups. While events handles the flow of information between device/app and the cloud, data is parsed via channels. Here’s how Apple describes it in its GitHub repo for SwiftNIO:
Almost every file descriptor that a user interacts with in a SwiftNIO program is associated with a single Channel. The Channel owns this file descriptor, and is responsible for managing its lifetime. It is also responsible for processing inbound and outbound events on that file descriptor: whenever the event loop has an event that corresponds to a file descriptor, it will notify the Channel that owns that file descriptor.Once the Channel is established, it’s up to the ChannelPipeline (a sequence of handlers) to process events. Those handlers can be inbound, outbound, or both, and process events in order. Handlers are also reusable components, and are designed to perform specific data transformations “which helps with code reuse and encapsulation.” It may be wise to consider SwiftNIO the same way we think of Metal, Apple’s framework for games. A good example of where Metal shines (pun intended) is Alto’s Odyssey, a new game that utilizes Metal to tap into an iPhone or iPad GPU more directly, but is written in Unity. So it goes with SwiftNIO, which isn't meant as a direct replacement for server-side Swift tools, but enhances them. In fact, Vapor, a notable service, is already using SwiftNIO, and trimmed 15,000 lines of code from its codebase as a result:
“SwiftNIO is designed to be a powerful tool for building networked applications and frameworks, but it is not intended to be the perfect solution for all levels of abstraction,” writes Apple. “SwiftNIO is tightly focused on providing the basic I/O primitives and protocol implementations at low levels of abstraction, leaving more expressive but slower abstractions to the wider community to build. The intention is that SwiftNIO will be a building block for server-side applications, not necessarily the framework those applications will use directly.” It’s a new wrinkle for Swift, and another hint at the platform's growing maturity. Later this year, Swift is set to receive ABI stability, which should be a real turning point. SwiftNIO is also open-source, and Apple encourages anyone to implement “out of tree,” especially if they’ve got unique use-cases or want to iterate away from Apple’s own release cadence.We have branches of Vapor and Fluent 3.0 built on #swiftnio successfully running and passing tests. Integration went very smoothly with few breaking changes. 🙌 With close to 15k LOC deleted so far, we think this is definitely the right choice going forward and we’re excited!
— Vapor (@codevapor) March 3, 2018
