Swift is a robust language for mobile, but cloud development opens the door to new opportunities for today’s top app developers. Integrating projects to backend systems can sometimes be problematic, requiring new tools and skills. It doesn’t have to be; end-to-end Swift opens the door to radically simpler app dev, so we can all focus on the engagement.
In this talk from AltConf, Karl Weinmeister demonstrates how easy it is to work with Swift on the server with the IBM Swift Sandbox and introduces IBM Cloud Tools for Swift beta app, which simplifies the management and deployment of server-side assets using a local development environment and complements a Swift developer’s familiar Xcode environment.
Swift is the number one growing language. It’s number 17 now, according to RedMonk, a firm that tracks language adoption. It cracked the top 20 most popular repos on GitHub, and has many contributors from Apple, IBM, and all over the community. And, according to a Stack Overflow survey, it is the most loved language! We want to bring that goodness that Swift has from the client to the server.
There are great reasons to use Swift: the power, the simplicity, the usability. It is just a fun language to work with, and there’s no reason we can’t extend its reach.
Modern Application Design (1:20)
There are different tiers of any modern application, and they have different characteristics. Your client apps have constrained CPU and memory. They are user-driven, whereas cloud services are virtually limitless in terms of the power. They are more event-driven.
As a developer, you want to put the right logic in the right place, and you want to take advantage of the profiles of each of these different tiers. Wouldn’t it be nice if you could use the same tools, processes, and patterns across both the apps and the services that you use? We want to bring those all together into an integrated developer experience.
Get more development news like this
Sharing Code and Tools Along the Way (2:08)
Let’s talk about some of the code and the tools that we are building with the community.
The first is the Swift Sandbox. Sandbox was released around the time that Apple open-sourced the language back in December of last year. It allows you to experiment with Swift with little friction.
You basically go to the website, and you can start coding in Swift. There are many examples of how to do things from sorting to tutorials that are in blogs that you can take a look at. It has some cool features, including saving snapshots of code you have worked on.
You have a login that can persist across different devices, so you can pick up where you left off. You can share your code and create short URLs, helpful for sharing questions on Stack Overflow. It also allows you to try different Swift versions. It’s able to run on Linux too, so you can quickly test how your code will work there.
One feature we added is that when you save your code, you can pick whether you want it public or private. If it is public, we keep track of what is floating to the top, i.e. what are people clicking on the most.
Behind it all, underneath the Sandbox is the Swift runtime. We have a consistent model between the client architecture and the server deployment.
We picture many Swift SDKs that can be used across both client and server. For example, on the previous team that I was working on, we built some of the Watson services for iOS at IBM. We would build a client SDK that talked to Watson, wrapped some of the REST services for various cognitive services, and we added a few client hooks.
For instance, when doing image recognition, you might have the ability to retrieve an image from a UIImage object, but there is no reason that we couldn’t have most of that capability exist in either environment.
Under the covers, many things are the same between both environments. With the foundation, we are continuing to build that out. We are adding Linux support and adding additional classes. It’s a work in progress, but we are making a lot of good progress towards achieving parity.
On top of that runtime, we are building an app server called Kitura that allows you to build REST services, APIs, and microservices
This month, we have had much interest from the community: over 40 non-IBMer PRs. We have had many stars, and we are using the latest Swift features.
It is Swift Package Manager compatible, and it supports a variety of different environments.
IBM Swift Package Catalog (7:03)
When building an app server or an app built on an app server, you don’t want to reinvent the wheel - you want to take advantage of any packages or libraries that are out there. That is why we built the Swift Package Catalog to help grow that ecosystem of whatever you need. If you need a blogger, if you need a JSON parser, you can look to the Swift Package Catalog.
We have released an integration back into the Sandbox. If you are looking at a package, you might look at a few of them and compare the READMEs and see which you like better. But sometimes, once you start using a package, it may not be exactly what you were looking for.
We have added sample capabilities so you can try those packages out in the Sandbox. It’ll import that package, have some sample codes so you can play with the interfaces, and see if you like that package before you invest in integrating it into your application. There’s already 1,500 packages (which I think is remarkable, because Swift 3 is still in progress).
Taking the Next Step in Simplifying Local/Cloud Deployment (8:36)
In addition to the Docker images that we provide, we are announcing a new tool called IBM Cloud Tools for Swift.
This simplifies that experience of taking your Xcode projects or your server-side Swift packages and deploying those to the cloud so you can create new projects. You can take some templates that we have to get started very easily and make updates, push to the cloud, and create a seamless user experience. You have this companion tool to Xcode that allows you to do everything all within one environment.
Let’s Take a Tour… (9:25)
Check out the demo app in the video above at 9:25. Robert shows a conversational bot that pulls in some of the Watson technologies for a dialogue, going back and forth and having a conversation with the user.
It’s a Slackbot, powered by the Kitura Swift server in the back end in the IBM cloud, and uses some of the Watson services.
IBM Cloud tools is still a beta, but since we want our users to get up and running with building Kitura apps and not having to write a bunch of boiler plate code, we created a tool to simplify that process.
For this demo, I’ll quickly create a Kitura app and get it up on our cloud hosting called Bluemix.
I am going to create an empty project, since this gives me a lot of control over what app I want to build. We have the option to add either client-side or server-side code. We also have the capability of adding in an iOS Xcode project and then automatically binding the URL to the web service through this tool.
I’ll create it on my desktop, and soon we’ll have the scaffold for building the Kitura app. In the sources directory, I open up the
main.swift file. We are going to deploy this. The deploying step usually takes about five minutes, but we’re getting it to be faster.
I will also show you how to create a Slackbot. This Slackbot allows you to write
/Watson and ask something like “Is it hot out today?” It then goes and fetches weather data from Weather Insights, in Bluemix, and returns us the current weather in the channel.
We used a natural language classifier to allow people to type in arbitrary questions to Watson, and it’ll get matched to whether you are interested in weather conditions or temperature.
I want the command to be
/Watson and then point to the web service URL that’s on Bluemix. We are going to validate against the token, and then on our web service, we just check to see if you are using a legitimate token for this command. That’s all you have to do to add this integration - it’s really fast.
Swift, Meet Watson and Slack (9:29)
We have made this repository public, so you can download the source code for this. Please file PRs if you want to add anything. Once you’ve cloned this, you have a directory. We have an Xcode project - you can develop in Xcode.
weather_question_corpus.csv, in the Config directory, I have a whole litany of different questions and what that maps to, be it temperature, conditions, or both. We can refine this to make the natural language classifier a little more robust.
If you push that corpus over to Watson, it builds the classifier. We can open up the project in Xcode, and what’s really neat about developing Kitura is that you have all of the features that xCode has. You can do type checking and you can add break points in your code. I can build and run it all inside of Xcode. You can also use Sublime (or your favorite text editor) and build it from the command line as well.
In the package.swift file, there’s a dependency manager that will automatically fetch these libraries. In
dependencies, we see a list of the libraries I am using. I’ve added in the Swift Watson SDK which allows us to use a natural language classifier to get the weather data.
All executables in Swift 3 require a main.swift file. This will be our entry into our code.
We create an HTTP server in Kitura, and we have it listen to a particular port. If you are running it in development mode, it’s going to be listing on 8090, but if you deploy it onto the cloud, the proxy is going to assign a port that you should be listening to because it maps port 80 to an internal port. We have written all of that code for you being able to listen to the appropriate port. Then, we create a new
All Kitura apps need a router, and the router handles taking an incoming request. I go ahead and create two routes: getting just a simple temperature, and a more advanced kind of route called
Slack is going to send us some data to us as JSON. We’d have to handle that message for a Slackbot. We can get the request object, the response object, and
next. It just hands off execution to the next thing in the middleware and the patterns.
Here, it’s really nice to be able to program in Swift for building web services, because there’s some really great language features you can use. For instance, I like to handle most of the business logic around a do-catch. Then if anything fails, we can send back a bad request response.
There is the notion of optionals and being able to unwrap it. You can check to see if the query coming in is well structured. You can unwrap the optionals and then abort early if any of those things cannot be unwrapped, using
Then we try to classify what type of message that was, whether it was asking about weather conditions or temperature, and then we send a response message.
That’s all you have to do to create this Slackbot. I encourage you to download the source code and play around with it. It does require you to have a Bluemix account, but that’s free.
Learn More About Swift @ IBM (22:07)
To learn more about all this, [email protected] brings it all together: it has links to all the resources here, and there are blog posts.
Q & A (22:35)
Q: You mentioned trying out a package by opening it in Sandbox along with sample code. Is there anything that package developers can do to support that, like providing their own samples?
Karl: One of the areas we have been really focused on recently is support for the package author. If you log in to the package catalog with either a GitHub or Bluemix account, you can update some metadata about your project. You can link to different samples, or attach the sample repo URL to your project. We have a whole admin interface for any of you that have written Swift Package Manager projects.