 My name is Suresh. I'm also working for a property guru. And my talk today is going to be about status of server-side Swift. So, just one second let me bring something here. I think you need to close something. Okay. So, why Swift has the potential to be a cool language for server-side programming? These are the reasons why it is cool. Why nobody talked about Objective-C being a potentially server-side programming language. And we're going to talk about Swift Package Manager, how to contribute to it. I will talk a little bit about some of the existing server-side frameworks like Perfect, Kutura, Vapor. And then the most cool thing, we are going to try to do a live demo. If you want to write your own framework, say there are Perfect, there are Vapor. But say, no, it's new. I'm going to write my own. How can we get started? So, we'll do a demo of that. So, why Swift has a server-side language? Since they went open source last year, I think Swift was announced like two years ago. And since they went open source, they have more than 2,000 stars. And the community is growing. There are more than 800 repos on GitHub with 100 plus stars. And every day, there are a lot of projects being put into the GitHub. So, the community is really growing. People are also a lot of interest. And if you write the server-side in Swift, you will have the same language for front-end and back-end. So, you can reuse a lot of models and logic. So, that's the advantage. And then, other than that, Swift has some cool language features. Like, of course, it is the first-class language. Good, very strong type. Compile time error checking. Some of the features of the functional language like MapReduce, Flatmap. We have that. Learning curve actually is quite easy. And then, moving from, if you are an Objective-C programmer, moving from Objective-C to Swift is actually pretty smooth. So, there are a lot of good reasons for us to explore this. All right. So, Swift Package Manager. Before I go deep into Swift Package Manager, there are some online resources that I'd like you guys to go back and watch. This guy, Honza, I think he contributes a lot in the open Swift community. He has contributed a little bit to the vapor framework as well. He talks in more detail about how to use Swift Package Manager, how to maintain the dependencies, and how to contribute. And then, Jesse's class, I think, is also a very famous name in the open Swift community. Also, a very good talk about how you can contribute to the open Swift. All right. So, the official documentation says, Swift Package Manager is a tool for managing the distribution of Swift code. It is integrated with the Swift build system to automate the process of downloading, compiling, and linking the dependencies. So, what exactly it is? It is a dependency manager. All of us are using a cooker pod or cartridge, right? So, it will help you do that one. On top of that, it's a build tool. It can actually, since Swift went open source, you can use it in Linux framework also. And you can use Swift Package to build your project, to test it. It's command-line-based, cross-platform, Linux as well as Mac, and then it's decentralized. So, this picture shows this command that is available as of right now in Swift Package. If you put Swift Package in there, if you are using Swift version 3, it will say there are some functions like Initialize. Init, Fade, Update, which will try to update your dependencies, download from the GitHub, and then put the dependencies in your project. It can also help you generate an extra project, which is very useful if you are a fan of Xcode. Apparently, not many people in the open source community. They are, because I've seen people already starting to write in Sublime, Veeam, cool. So, yeah. And so this is the structure of the Swift Package Manager. Once you generate, once you hit Initialize, it will create a, this is like, this is what will be generated. You have packages that Swift, you have sources folder where you will have a placeholder file, test server that Swift, for example, this package was called test server. And then you have some test files as well. And your package, the package that Swift file looks like this package, and then the name. If you want to add dependencies or linkage with certain targets, you would specify there, which has, it has some rules, some convention. I think if you go back and watch that talk by Honza, he will give you a better understanding of how it is done. Also, I want to give a story about the Swift version manager. If you are, because Swift 3 is not officially released yet, even though I think July 29th or 20th is the final day of the evolution, after that any changes will go to Swift 4.0. So before like, I mean, until Swift 3.0 is officially out, you can use Swift version manager to actually manage the versions of the Swift. So it works a little bit like the Ruby environment. You can install using brew, that command. And then these are the options available. It can display what are all the options, Swift versions available using the versions command. And then you can like, set it up to a directory level by saying, okay, Swift ENB and then local, and then use 3.0 or some snapshot of Swift 3.0. And then for that directory onwards, it will always be diverse on the Swift. If you don't want this, then you can just change back. Pretty cool too. In our live demo, we're going to show how it is done. So this start from GitLogs. So these are the top existing frameworks. If you search for language, Swift and topic server, these five are the top one. Everybody heard about Profect and Kittura and the priority paper. So we'll just give an example of Hello World in these top three languages, how it is done in Perfect, Vapor and Kittura. I think Perfect started even before Swift went open source. And these guys were saying once and when Swift does go open source, people will start writing server-side language in Swift. And then we are going to be the number one tool when that happens. And apparently, I don't know if that is the case right now, even though they have the most trust, but I think Vapor is catching up. I think they started with two guys from Canada, and then there was a company who sponsored them, saying, okay, you guys keep writing, we'll give you money. And then they got those guys kept going. So you have to write a global function called this Perfect server model. You have to initialize it. And then you define your request handler, in this case, Hello World handler. And then this request handler will have a method called handleRequest. So whenever request calls, everyone will handle it. Once you define your routing there, in our case, it's slash. And then in the response, you append Hello World, you complete the request. So when you use this route slash, you need to return Hello World. In Vapor, it's very concise and even easier to read. Call it Droplet. It's more like a routing server. You define and then you define a rule like, okay, get method slash. It has a callback with request. Now the request will only return Hello World. You can return it from the string, JSON, or even the HTML views or whatever you like. Vapor, I think, they have in the GitHub, it's called Qfiori. And if you go, they have one very cool thing is they have this OpenSwift. In OpenSwift, they have a few projects like S4, a lot of things. The main reason is they want to set some standards for OpenSwift server community. So even if you are writing your own framework, there are certain standards that you don't want to rewrite again. So everybody followed it like HTTP, 1.1 rules, those error codes, all those things. So it's a very, very cool resource. You can go back and check. It's called OpenSwift. And Qtura are initialized by IBM. I think they were inspired by Express.js. And they also invested in the company was doing the Express.js. So if you are very familiar with Express.js, the Qtura framework will sound very familiar to you too. It was pretty similar to Vapor. You create a router and then you define what you want to do for certain endpoints on router. And then you start the HTTP server on port and run. So a simple example of how the hello world is done in three frameworks. Now, writing your own framework. Why? You ask the question why you want to write your own framework. There are so many other languages. Well, the thing is, Swift is still pretty new and then there is not a clear winner yet, right? There's Vapor. There's Perfect. But I don't think anybody can say, okay, we are going to be the next Express.js or next Ruby on Rails. So you still have a chance. Write your own. And ask your friend to contribute. And then slowly maybe you could do on the top, right? It's cool. So, and then if you actually go and read their codes, you'll find there are a lot of things which are very similar. At the low level, they are all like for HTTP web framework. They are mostly like, they have to deal with socket right here to create socket. Either UDP or TCP socket and then you just make the communication happen. You open the socket code and then wait for the connection to happen. And then you accept the connection and then you send some data and then your client will get it. So I'm going to show you this. We're going to talk about TCP server here. So I'm going to show you the basic flow. I think you might have studied in networking class in university. So in server side, you create a socket. You bind it to address. Then you listen for incoming requests. And then once there is some connection coming from the client, you accept it. All right, you block until the connection from client. So you accept it. And then if you want to read, you read it. If you want to write, you write and then you close. So that's it. Very simple. Just a few steps. The key thing is if you want to do it on your own in Swift, you have to know actually how to access the lower level C API in Swift. Believe me, I'm not a fan of C language. I mean, I did in university, but now when we're using Swift, C feels like wow. So, but actually it's not that difficult. I mean, Swift has made it very easy to actually go back and actually use some of the system APIs. For example, this here in dot C in the C language, you have this function called socket, right? This will create a socket and return your descriptor. It will take in three parameters, domain, type and protocol. So if you want to use this API in Swift, you just have to check, OK, if this is a Linux version, I want to import this G, LIBC, this framework. And if it is a Mac operating system, I want to do it Darwin because this API is available in one of these frameworks depending on the operating system. And then I say this socket, this method, I give it a name for a socket and then for Darwin, this socket. So now in my code, I can just use the socket no matter what my operating system is. So it will look something like this. And if you have like a very repetitive C language that you want to use frequently, instead of like going, writing these if-else and if these things you can actually create a Swift module like a Swift package manager of the existing C. The key is to, you have to edit your model dot model map of the package manager to ask to say which header file you want to put in there. I think the Swift package manager has some example of how to do it. So if you're interested, you can go and have a look at this. I think the link is here. So demo. So we're going to talk about Swift package manager. We'll do, we'll write a TCP socket, TCP server and try to run and do a simple hello world. When the client requests for it, the server will region hello world, okay? So, yeah. All right. So, inside, let me remember it. Simple, simple, simple. We create a framework called Cobra, okay? So let's do it, anything there. So we'll initialize the Swift package manager. Swift package init. So if you, oops, sorry. It didn't work. Why it didn't work? All right, I'll show you. So, I have these three versions, and the current version it is using is 2.2. Since Swift package manager is available only in Swift 3.0 or the snapshots of it, it didn't recognize the command so it didn't do anything. So let's change our Swift versions to 3.0 for this directory only, right? Swift environment local 3.0. Sorry. This is not supposed to happen when you're doing live demo, right? So now, Swift version 3.0. Okay, very good. So, all right. We created this directory. We have package, source, test, all right. Since I want to write in Xcode, I want to create an Xcode project also. So, okay. So it generated an Xcode project. If you look at it, now you have an Xcode project here. So, let me open this. Let me open this using Xcode beta. So, I'm going to write in Swift 3.0. Okay, we're here. All right. So we have this file here. So, let's name these two topics. Since we want to create a topic, just name it, all right? So, you want to import the socket APIs into this file. So, it is... All right. At this point, it is showing... It is saying there might be an error. So, let me try to build this. It will say error. So, this error is... Because this version supports the legacy Swift, which is Swift before 3.0. So, it says you have not set your legacy version yet. So, it doesn't know whether you are using legacy. So, let me go back and then select here and change the legacy to known. So, I'm telling it, so I'm not using the versions before Swift 3.0. All right. So, somehow, if I do not restart my Xcode at this stage, the code sensing will not work. So, I'll just quit it and restart the Xcode. I think we have all seen this. All right. So, now I try to build. It's okay. So, now, we want to import the thing, right? For Linux, we want to import this one. For Mac, we want to import Darwin. Now, we want to create a variable with the same name so that we can use it in the same way for both versions. And for this one, you don't take that one. Later, I'll use some code snippets so it will be faster. This one I want to show you. All right. So, we have this. So, let's define some errors that we might encounter when you are dealing with the server. So, let's define those errors right now. So, this error type was modified to error protocol in Swift 3.0. So, you have this error protocol. So, let's create some error connection time now. I'll paint something like this. And like I showed you in the PowerPoint before, the socket is represented by a descriptor. It's an integer 32 type. So, let's create a type alias for that one. 32 and then 44 is also an integer 16. So, let's create that one also. 16. All right. So, we have this now. Now, let's go ahead and define socket. We are going to define it as a protocol. Let's call it socket. And then we have a variable called descriptor, which is a descriptor type. And we are going to define a function and call it close. This might throw error. Okay. So, let's create a method in this socket. Say, to create a socket. We are not going to pass any parameters here because we want to create the socket in the default setting, meaning localhost using the available code. It will return a descriptor. Okay. So, remind you again, this API, C API, this socket, it takes in three parameters. IP type, whether it's IPv4 or IPv6. The second parameter is the data type. And the third parameter is the protocol type, whether you are using TCP or UDP. So, this is how the C API looks like. So, let's try to create a socket using this one. So, for our case, we have this S socket, right? So, this, if you go to the terminal socket, so you have this function over here. We just use S socket since we have already defined it to be that one. So, we are going to use IPv4 here. In part two, I need, this will represent version four. I need six would be six. So, we are going to use this one here. Stream type, we are going to use socket stream. And then for protocol, we are going to use TCP protocol. Proto, TCP. All right. So, we want to make sure that this descriptor doesn't return error. So, the value should be, sorry, we can minus one. Otherwise, we want it to throw socket error. Now, it should be able to return this descriptor. Okay. But, in reality, when you are creating socket, you have to be, you have to kind of, there are two things you have to do. You have to create socket option to tell that I want to reuse this address when the connection is ongoing. And then you have to, for a MAC operating system, you have to kind of disable socket type error. If you don't, then when you are, for example, if you are running this on iOS, you go to background mode and come back, the connection may drop, and then you get some unwanted exception. So, to disable those, you have to, we'll come back to this one later. So, now we have this method. It will create a socket for you. Okay. Now, let's go back and do these two methods. Create a new file. It's called socket plus points. Sorry. Sorry. The reason is the file is created. Now, to decrease, I'm going to delete. You can create here. Okay. So, I'm going to use the questioning page so that I don't have to type everything. So, I have two methods here. So, socket options. It is asking, okay, for this socket, please reuse the address. And then this one, it will create a process by disabling the supply. The detail, of course, these are available in the CAPS. If you are very interested, actually, this is a very good resource. Nice command. Not very long. Some online resources to read about this how to get going. All right. We have socket now. Now, let's write some functions more specific about TCP socket. Let's go back and create another file called TCP socket. All right. So, it will confirm to this protocol. We have a descriptor. We have a initializing method. We should take... We're making it optional because if you haven't provided a descriptor, means you haven't provided a socket. Remember, in this case, descriptor means a socket, right? If you haven't provided it, it will create a different socket for you. But we have to provide a port. All right. So, type it. So, set the port. So, we have a port available. It's here. And then, if the descriptor is not new, we'll set that as our descriptor. Otherwise, we'll ask it to create new one from the scratch using the method that we defined before. This is socket.createSocket. Since it throws, we'll have to try it here. Since we have tried this, we'll put it like this method can actually throw. Okay. All right. All right. So, this is companion because we haven't implemented the close function that this protocol takes. We'll go back to that. Come back to that later. So, other than that, if you remember the protocol I showed you in the descriptor socket, it has some methods like XS, close, bind, right? Let's write it down. What are the methods? First of all, there's a method called address. Basically, what it does is it will create the address. In your cases, you are going to define the address for your server. In our cases, we are just going to use the default. But this address, this socket has to read in its own format, right? It's a C struct. So, this method will basically take your address like localhost or whatever and convert it into the C address. We'll do that method. And then you have methods like bind. Bind to that address. Listen for connection. Connect. Accept the connection. Send data to that and then find close. Since close is part of our protocol, let's go ahead and implement this first. So, it will just close and then if it can close, it will just close. All right. At this time, you are saying error here because this socket close is a method that I have not embodied here. I will post some of it which are important. All these things. So, here, like we did before in socket here by this one, we are importing some of the C API here and then giving them the same name in the Mac and the Linux so that it can be used with the same name. So, close once and it's done. Let me go ahead and fill out the address. So, it's using the default. So, there is something that is different in the Linux and Mac. So, I have to do this. Bind. It will bind this socket with this address. Listen. This is listening for you coming. This size you can define. It will use the default value. Connect. Again, this is a very basic demo of creating a server in suite. So, there are a lot of cases you have to do different kind of checking. So, you can consider it's a fully functional but it can get restarted. Accept method. So, one thing to note here is in this accept method, when the socket accepts, it will create another socket. It will create another descriptor and give it back. This becomes the client in your PCB server. So, let's go ahead and do that one as well. Just call it tcp server. Okay. All right. It has a port. It's going to create a public initializer. So, what we actually want this server, once you define the server, you want to start the server and then you start, you know, giving the response that you want. So, let's create a function called start. And then you want to return something so that you can append the response in it. So, we'll return our handler with handler. Handler is a callback. We'll define it here. So, let's go here and then define our handler where it will take in tcp socket. It can actually throw it in. So, we'll use this one here. Okay. So, we have this method. Once we start it, it will create the tcp socket, the server socket for you and then start listening for incoming requests. And when it does, when it gets it, it will accept it and then it will return you the new socket that it created after it accepted. Because here, we said the accept method after it accepts it will return another tcp server. So, let's do this on tcp server socket using a descriptor. Since we don't have any, just put it now and use the port here. Server in bind. It will use the default address that we defined before. Start listening for it. All right. Now, let's say it listens and there is a request from the client. So, it has to accept it, right? Let's say the operator would accept. It accepts the request from the client and then we want to return this to the handler. So, the key now here, one important thing to notice is we don't want this connection to fall back. Okay. The server has started and then it accepted the request and then nothing happened. We want the server to, this start method never to end, right? We want it to keep listening to the incoming request. So, we'll create a loop here which will never be wrong. So, what it does is because this is always true, it will never go out of this loop. Since this never goes out of the loop, we'll use this keyword called no return, which we stressed that this method is not supposed to return anything unless some exception happens. Okay. So, at this stage, we are done with creating the basic server. So, let's build and make sure everything is working. Now, we want to test if it is working or not. So, to test, let's create a command line application in Mac. It's called target. Mac OS, which is the command line. This call is Cobra server. All right. So, it will create a command line which has a main flood sweep. If you are writing a script in Swift, this is also, you can create the command line target in Mac OS and then write it here in the main flood sweep. Now, import our modules here. If you get it, we want to print it out. Okay. So, let's create a server. TCP server. Let's say we didn't use this one. Server start. It will give us back the client and then we want to append some message to this client. All right. So, let's say, we want to send it a message say, hello from PG. All right. So, I want to send. Since it is sending an area for this one, we want to convert this message into an array. Bites. Hopefully, everything is working fine. It will be this Cobra build is successful. Let's try to build this one. All right. We have an array. Okay. It will be successful. Let's run it. Okay. So, it looks like our server is up and running right now. Let's test it. It is true. So, let me say, okay, there we have it. Hello from PG. So, we just finished making the server in port edge region. Let's close it. Just to make sure I'm not cheating. Okay. Okay. Let's send another message. Okay. That's it. So, demo is over. So, if you have any questions. No questions? Yeah. Are there any database connections or libraries you said? Yeah. Actually, perfect has come to connect to Mongo, Postgre, and MySQL. If you go back and look at their code, they have a lot of regional developers. Vapor is writing it too. So, yeah. There are already a few of them. Is anybody actually using right? Yeah, actually, I think there are people and we are actually going to use a chemistry demo of XC UI test and Garkin's drive. And then you are using some server written in Objective-C to run the network to mock the network request. Actually, we can use this server for that purpose as well. So, there is a lot of use cases. Even if you are not building a real server, you can use it in your application. Wow. So, when you mock it, you replicate some back-end code? There is a server. What is it called? Yeah, yeah. So, I'm actually using it right now. So, it's not really up to date. So, I think, hopefully, you can actually view all servers to work as a teacher. But I'm thinking if you do permutations or that the logic that you are doing from the server has to apply from the app, right? You have to replicate some business logic code across, right? Yes. Okay. I just want to add, you mentioned Objective-C server, right? Back in the 90s, when Apple had web objects, normally you heard of it. That's where call data came from, right? Interesting. It shows my age, right? Any other questions? Okay. Thank you. Thank you.