Today at the Swift Summit in San Francisco we announced the availability of Kitura 2.0, as well as a number of other tools and capabilities that form part of the Kitura 2.x ecosystem.

The first versions of Kitura were released less than two months after Swift was first open sourced and Linux was available in the Swift 2.1 development stream. At that point Swift itself was at an early stage in its own evolution, with breaking changes to the language occurring on an almost daily basis and with the community of Swift developers only just starting to understand what made an application or framework “Swifty”. As a result Kitura, like most of the early Swift web frameworks, was modelled on an existing framework in another language. In Kitura’s case, that was Express (which in turn describes itself as being inspired by the Sinatra framework in Ruby).

This has meant that, whilst Kitura has provided a flexible and powerful set of capabilities, is has provided a programming model that may not natural to a Swift developer and that does not exploit some of the advantages of the Swift language.

Kitura 2.x and its ecosystem aims to improve that, starting with the features provided in 2.0 which will be built on in future updates to Kitura 2.x, providing a cutting edge set of features that fully exploits the power of the Swift language.

Kitura 2.0: Introducing Codable Routing

One of the major new features of Kitura 2.0 is “Codable Routing“. This takes full advantage of the new Codable capabilities provided in Swift 4.0, as well as Swifts strong-typing system, to provide a new way to create web APIs.

Traditionally web frameworks require you to think in terms of web requests and responses, with HTTP headers and status codes, and dealing with parsing body data which is typically encoded as JavaScript Object Notation (JSON). This both requires knowledge of how web APIs are constructed, and a change in programming model mindset.

Codable Routing changes this by allowing you to create web APIs in the same way that you would any other asynchronous function in your application: by defining functions with receive parameters with standard Swift types, and that respond with a completion handler. The only requirement is the the parameters must conform to Codable, hence the name.

This not only simplifies the process of creating a backend server for use by an iOS application client, but also requires you to write between 4x and 10x less code, reducing the scope for programming errors.

KituraKit Optimized Connector for Kitura

Creating Web APIs using Codable Routing radically simplifies building a backend server, but that only provides one half of the solution. If you still have to make requests from the client application using web requests with JSON encoded data, then some of the value of using Swift types and standard function calls is lost.

Whilst the Codable Routes created by the Kitura server are standard web APIs, usable from any application regardless of client library used or which language the client is written in, Kitura provides a bespoke, optimized client connector in the form of KituraKit. KituraKit provides a mirror image of the Kitura Codable Handler APIs, making it very easy to share Swift types, and in the future protocol defined APIs, between the client and server in the form of a Client/Server Contract.

Client/Server Contracts and KituraContracts

KituraContracts enables you to create a client/server contracts, defining the types that are used when passing data between a client and a server. This currently this includes Swift types that conform to Codable, Identifier and RequestError, allowing you to share data types and the functions on those types. During the lifetime of Kitura 2.x, Kitura Evolution proposals are expected which will expand the capabilities of KituraContracts to include sharing protocol based API definitions and templates for common web APIs such as data persistence.

Kitura Command Line Interface (CLI)

In addition to the simplified APIs provided by Kitura and KituraKit, working with Kitura has been made significantly easier through the availability of the Kitura CLI. Kitura has long provided the ability to quickly create a “starter” application that sets up Kitura with capabilities such as configuration and monitoring built in, as well as “select the capabilities you want” starters through the use of the “swiftserver” generator. Additionally those applications have provided Dockerfiles, designed to allow you to build, run and test your server application directly on Linux on your laptop. This has however required you to use several separate tools.

The Kitura CLI brings these all together in one place, providing “kitura init” as the way to start writing any Kitura application, “kitura create” to build a start application with additional capabilities, along with “build”, “run”, and “test” capabilities to work with Kitura on Linux inside a local Docker container.

The Kitura CLI also provides “kitura kit” as a way of getting the latest KituraKit bundle for iOS, which can then either be directly imported into your application or added as a CocoaPod.

Commercial Support for Swift on Linux, and for Kitura

Finally, we also announced commercial support for Swift on Linux, available in two levels. The first covers Swift itself, including Foundation and Dispatch, which can be used in any environment or cloud, and with any application or web framework including Vapor and Perfect. The second level extends this with support for Kitura itself, and all of the packages in the IBM-Swift GitHub organisation that form part of the Kitura ecosystem, as well as the SwiftMetrics monitoring capabilities.

This is all just the start of the Kitura 2.x roadmap, with many, many more capabilities and features are under consideration. In August we launched community playbacks and the Evolution process, including the manifesto of which Codable Routing was one of the items. We’re keen to hear more thoughts and ideas from the community on where Kitura should be headed and whether its on the right track. Anyone can do that through any numbers of means, including Slack, Issues, PRs, Evolution and Playbacks – or leave a comment below!

Try it out!

If you want to try out Kitura 2.0 and its new features, try out the following two tutorials:

  • FoodTracker Backend
    This builds a Kitura backend for the FoodTracker iOS application that is provided as part of the Apple tutorials for building your first iOS app. This uses Codable Routing to build the server, and updates the FoodTracker iOS app with KituraKit to be able to store and retrieve data from the Kitura server.
  • ToDo Backend
    This builds a Kitura backend that passes the specification and tests for the ToDo web client using Codable Routing. Additionally we provide an example iOS app implementation of the ToDo web client that uses KituraKit to communicate with the Kitura server.

Join the discussion on Slack Learn more at Star Kitura on GitHub

6 comments on"Introducing Kitura 2.0"

  1. Good news!
    By the way, do you plan to build Docker image?

  2. Hey any updates on calling SQL Server in Kitura. I posted the question on community a while ago,
    I would love to be able to make an API on Kitura which connects to MS SQL Server Backend.

    • Chris Bailey February 06, 2018

      Hi Apkia. There’s a couple of options that I’m aware of. “SwiftKuery” lets you connect to and use SQL databases, with support for PostgreSQL and MySQL. I’m not aware of anything that works specifically with MS SQL Server though.

Join The Discussion

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