Sinds Apple Swift oorspronkelijk leerde kennen als de opvolger van Objective-C, is de manier waarop het netwerk iOS-, macOS-, watchOS- en tvOS-applicaties codeert veranderd.
Op het moment dat Swift een open-source-fase werd, opende het nieuwe denkbare resultaten voor de taal die verder ging dan mobiele en client-side applicaties. Swift veranderde ook in een server-side-taal. In deze instructie-oefening zult u zich realiseren wat Swift aan de serverzijde is en waarom u Swift op uw back-end zou moeten hebben.
De server-side Swift-activiteit wordt gestimuleerd door drie prominente projecten, Vapor by Qutheory, IBM's Kitura en Perfect, met als doel om Swift-ontwikkelaars een kans te geven om volwaardige back-end-administraties op te zetten. Dit zal dergelijke ingenieurs fundamenteel veranderen in full-stack ontwikkelaars, waardoor de vereiste voor afhankelijkheid van Node of PHP ongeldig wordt of controle wordt geboden aan een BaaS-fase, bijvoorbeeld Google's Firebase.
Doelstellingen van dit artikel
In dit artikel gaat u in op de server-side Swift. Eerst zal ik uitleggen hoe Swift aan de serverzijde werkt, en daarna zal ik u de best practices demonstreren om te beginnen met de Kitura-, Vapor- en Perfect-systemen.
Introductie van Server Side Swift
Swift werd voor het eerst aangekondigd door Apple in 2014 en werd al snel een van de snelst ontwikkelende programmeertalen. Swift put uit een groot aantal van de beste hedendaagse talen, bijvoorbeeld Python, waardoor elegantie en gebruiksgemak mogelijk zijn. Het bevrijdt ingenieurs van de gespecialiseerde ketenen van Objective-C, waardoor steeds vloeibaarder en instinctiever werk mogelijk wordt.
In december 2015 deed Apple opnieuw een fantastische verklaring en maakte de Swift-taal naast zijn ondersteunende bibliotheken, debugger en pakketbeheerder een open-sourceproject onder de Apache 2.0-licentie, waardoor het platform werd geopend voor mensen in het algemeen om pull-verzoeken in te dienen en bij te dragen. De verplaatsing ver van Objective-C heeft niet alleen de talrijke Objective-C-ontwikkelaars die aan de App Store hebben bijgedragen, verleid, maar het heeft het voor ontwikkelaars van alle vaardigheden en grondslagen ook eenvoudiger gemaakt om met Swift het Apple-ecosysteem te betreden.
Hoe dan ook, hoewel Apple's ontwikkelingsapparatuur het aantoonbaar gemakkelijker heeft gemaakt voor ontwikkelaars om uiterlijk overtuigende en boeiende apps voor de App Store te ontwikkelen, was een prominente bottleneck dat projecten nog steeds gespecialiseerde back-end-ontwikkelaars nodig hadden om complexe informatiegestuurde applicaties te ontwikkelen. Dus iOS- en macOS-ontwikkelaars zouden ofwel de hulp moeten inroepen van Python-, PHP- of Node-ontwikkelaars om hun back-enddatabase te maken, of zelf de mogelijkheid moeten krijgen, waardoor er een nog zwaardere taak overblijft om hun doelen te bereiken.
Hoewel back-end-as-a-service (BaaS) de held van iOS-ontwikkelaars is geweest, met back-end-oplossingen zonder code, bijvoorbeeld Google's Firebase en Apple's eigen speciale CloudKit die de complexiteit van de back-end verminderen, talrijke groepen en ondernemingen vragen om meer. Dit is de plek waar server-side Swift binnenkomt, waardoor je een volwaardige multi-threaded back-end-server kunt maken die open source is en eindeloos configureerbaar.
Server-side Swift geeft u de kans om te kiezen hoe u uw back-end-server heeft, ongeacht of het gaat om AWS, RackSpace of uw eigen fysieke servers. U kunt ook kiezen hoe u uw servers in evenwicht wilt brengen (bijvoorbeeld door middel van prominente serveroplossingen, bijvoorbeeld NGINX) en hoe u uw informatie in een database wilt voortzetten (of het nu gaat om NoSQL-arrangementen, bijvoorbeeld MongoDB, of traditionele databases, bijvoorbeeld , Postgres, MySQL of Oracle). Dat, en u bent nooit gehecht aan een onderdeelarrangement, u kunt overschakelen zonder de codebase van uw hele applicatie te beïnvloeden.
Het feit is dat door te kiezen voor een open-source Swift-arrangement aan de serverzijde, bijvoorbeeld Vapor van Qutheory, IBM's Kitura of Perfect, u een enorme reeks modules exploiteert waarmee u uw back-end kunt ontwerpen, alleen de manier waarop je het nodig hebt, door gebruik te maken van de mogelijkheden van je huidige groep in Swift om dit als zodanig te doen.
Server-side Swift klinkt absoluut overtuigend, maar welke structuur is ideaal voor jou? Vervolgens onderzoeken we ze allemaal op dezelfde manier, te beginnen met Kitura.
Te beginnen met Kitura
Beginnend met Kitura, heb je een fase die voor het eerst werd uitgebracht in februari 2016 en kort daarna onmiskenbare kwaliteit oppikte op Apple's WWDC, in gesprek met IBM's invasie om server-side web te ondersteunen met Swift, dat vervolgens werd ingesteld om van Apple's handen naar open source.
In de regel is Kitura gecentreerd rond traditie in plaats van configuratie. Het bouwt uw onderliggende project uit met stubs, voordat u de expliciete frameworks en bibliotheken selecteert die u hoopt te bouwen. Het authenticatieproces van Kitura wordt ondersteund door zijn uitzonderlijk eigen Kitura-Credentials middleware-raamwerk, waardoor u een buffet van validatiesystemen kunt overzien, van de conventionele gebruikersnaam / wachtwoord tot online netwerkaanmelding en uniforme verificatie, met behulp van OpenID dat JSON Web Tokens (JWT) afhandelt .
De ORM-indeling van de Kitura-database wordt beheerd door Kuery om de complexiteit van het specifiek beheren van SQL door elkaar te halen, door rationele basisdatabases te ondersteunen, bijvoorbeeld MySQL, SQLite en PostgreSQL lokaal, en daarnaast andere database-arrangementen, inclusief NoSQL-databases, via de verschillende andere plug-ins.
Kitura biedt bovendien andere waardevolle plug-ins voor zaken, bijvoorbeeld HTML-sjablonen, waarbij gebruik wordt gemaakt van bekende plug-ins, bijvoorbeeld Stencil en Markdown. Afkomstig van IBM, profiteert het serversysteem bovendien van connectiviteit met IBM Watson API's en biedt het bovendien macOS-ondersteuning voor directe coördinatie in hun Bluemix-cloudplatform. Dit geeft u een extra keuze, naast uw andere conventionele implementatie-alternatieven, kruiselings over Linux / Unix- en macOS-servers.
Hoewel het platform absoluut een buitengewone reeks functies biedt van Kuery tot de capaciteit om te integreren met de verschillende IBM API-bibliotheken. Het heeft niet de netwerkkracht die Vapor heeft. Het ontvangen van Kitura vereist het erkennen en begrijpen van zijn eigen niet-reguliere methoden om dingen voor elkaar te krijgen, van hoe Kuery werkt tot zijn authenticatiemechanisme. In ieder geval, gezien het feit dat het wordt gesponsord door een uitgebreide organisatie met aandacht voor het streven, zijn er enkele toekomstverzegelende affirmaties aan gewerkt.
Kitura installeren en uitvoeren
De handigste methode om te beginnen is door Kitura's direction line interface (CLI) te gebruiken, die wordt ondersteund op zowel macOS als Linux. Gebruik het bekende hulpprogramma Homebrew voor pakketbeheer en installeer Kitura en Kitura CLI door het volgende in te voeren:
$ brouwtap ibm-swift / kitura $ brew installkitura |
In een niet-gevulde organizer die u als uw onderneming zult gebruiken, voert u de bijbehorende handleiding uit om uw onderneming te bevestigen:
$ kitura init
Op het moment dat het klaar is met het produceren van uw skeletapplicatie, ziet u een ander project genaamd HelloKitura.xcodeproject. U kunt meer te weten komen over het genereren van projecten door de documentatie van Kitura te raadplegen. U kunt het recentelijk gemaakte project openen in Xcode en de essentiële applicatieklasse, Application.swift , wijzigen om alle oproepen naar de root van uw server https: // localhost: 8080 / URL :
// Behandel HTTP GET-verzoeken aan "/"
router.get ("/") {verzoek, antwoord, volgende in
response.send ("Hallo, wereld!")
De volgende()
}
Het bovenstaande codestuk reageert door het voorbeeldige Hallo, Wereld! . Voordat u het project eindelijk kunt uitvoeren, wijzigt u uw Xcode-schema zodat het naar HelloKitura (uw actieve project) verwijst, en begint u uw onderneming door op Command-R te drukken. Terwijl uw server actief is, gaat u in een browser naar keuze naar https: // localhost: 8080 en u zou de hello-wereld in uw browser moeten zien.
Te beginnen met Vapor
Uitgebracht een paar maanden na de Kitura, in september 2016, wordt Vapor van Qutheory over het algemeen als de meest prominente beschouwd met betrekking tot de gemeenschapsgrootte en het aantal modules. Het is gebouwd bovenop het Swift-nio-framewerk van Apple, waardoor het een echte krachtpatser is. Helemaal niet zoals Kitura en verschillende stadia, die niet simpelweg in Swift worden gemaakt, maar in plaats daarvan op Node.js of andere middle-person parsers, ontkoppelt Vapor zichzelf van al die afhankelijkheden om een Swift-parser te leveren en duidelijke en coherente API's te geven.
Vapor geeft grondige hulp van databases aan SQL-leveranciers, bijvoorbeeld MySQL en PostgreSQL, en NoSQL-leveranciers, bijvoorbeeld Redis en MongoDB, als Kitura. Hoewel Kitura zijn eigen Kuery ORM-oplossingen heeft, gebruikt Vapor Fluent ORM om de databases te ondersteunen waarnaar ik zojuist heb verwezen, waardoor het redelijk eenvoudig wordt om de ORM uit te breiden naar andere externe databaseproviders. Vapor isoleert zichzelf van alternatieve frameworks door native ondersteuning van Apple's Push Notification Service, en ondersteunt ook SMTP voor het pushen van e-mailmeldingen.
Terwijl Kitura zijn eigen authenticatieraamwerk actualiseert, heeft Vapor de Turnstile-authenticatiebibliotheek van Stormpath native ingebakken. Net als Kitura ondersteunt het platform ook de Moustache en Markdown verleidt, en naast zijn eigen Swift-native expressieve templating-taal, begeleidt Vapor ook zijn eigen CLI-motor, net als het andere server-side Swift-framework, met de capaciteit om de applicatieopdracht uit te breiden. -regelargumenten met aangepaste vlaggen.
Installeren en uitvoeren
Om met Vapor te beginnen, begin je met het installeren van de Vapor-toolkit, die alle bibliotheekafhankelijkheden en de CLI-toolbox bevat. Installeer het met Homebrew door het volgende in de terminal in te voeren:
$ brew installvapor / tap / damp
Op het moment dat de installatie is voltooid, kun je bevestigen dat Vapor met succes is geïnstalleerd door vapor —help te typen. Om een project te maken, typt u het volgende, vervangend door uw eigen projectnaam:
$ damp nieuw
De Vapor-engine zal een mappenstructuur bouwen die lijkt op het volgende:
├── Openbaar
├── Bronnen
│ ├── App
│ │ ├── Controllers
│ │ ├── Modellen
│ │ ├── boot.swift
│ │ ├── configure.swift
│ │ └── routes.swift
│ └── Rennen
│ └── main.swift
├── Tests
│ └── AppTests
└── Package.swift
Om daadwerkelijk een Xcode-project te maken, moet u ook expliciet de volgende opdracht invoeren vanuit de projectmap:
$ damp xcode
Ten slotte, om uw project te bouwen en uit te voeren, selecteert u in Xcode het schema Uitvoeren en ook het ontwikkelingsdoelapparaat van My Mac , en drukt u daarna op de knop Uitvoeren, net als bij elk ander Xcode-project. Aangezien uw Xcode-project geen fouten vertoont, zou u het volgende bevestigingsbericht in de terminal moeten zien:
Server begint op https: // localhost: 8080
Ga je gang en voer die URL in elke browser in, en je zou je applicatie moeten zien draaien.
Beginnend met perfect
Ten slotte kijken we naar Perfect van PerfectlySoft, een feature-rijk server-side platform zoals Vapor en Kitura. Perfect bevat dezelfde standaard toeters en bellen die je zou ontdekken bij eerdere leveranciers, van sjablonen met Moustache of Markdown tot netwerken met websockets, en daarnaast Apple Push Notification en SMTP.
Net als het andere server-side platform heeft Perfect zijn eigen ORM-implementatie, het StORM-platform (Perfect StORM), dat native ondersteuning biedt voor MySQL, PostgreSQL en andere prominente relationele databases, en daarnaast MongoDB, Redis en andere NoSQL-oplossingen. Een prominente uitsluiting van Perfect is een CLI, maar het framework maakt dit goed met een native macOS-applicatie.
Net als Vapor heeft Perfect bovendien Turnstile ingebakken om het authenticatiemechanisme van stroom te voorzien, uitgebreid om intiemer met StORM te communiceren. Een andere kwalificatie die deze regeling ten opzichte van de andere heeft, zit in een aanzienlijk aantal van de native hulpprogramma-bibliotheken die het ondersteunt, inclusief hun eigen unieke cURL-wrapper en extra tools voor het werken met bestanden en mappen. De ontwikkelaarsbasis van Perfect is de op een na grootste en houdt bijna gelijke tred met die van Vapor, wat betekent dat je een sterke community hebt om dit platform te ondersteunen, naast een rijke reeks educatieve bronnen die je zekerheid geven over de kans dat je het kiest.
Installeren en uitvoeren
Aan de slag gaan met Perfect is buitengewoon eenvoudig. Kloon in eerste instantie de PerfectlySoft-opslagplaats door het volgende in te voeren:
$ git clone https://github.com/PerfectlySoft/PerfectTemplate.git
Bouw vanuit de gekloonde map het project:
$ snelle build
Voer ten slotte het project uit, dat een lokale server zal draaien op adres 0.0.0.0:8181
.build / debug / PerfectTemplate
U kunt uw project ook op Xcode uitvoeren door eerst een nieuw project te maken, als volgt:
$ swift pakket gener-xcodeproj
Zorg er binnen Xcode voor dat uw uitvoerbare doelwit naar Mijn Mac is gericht voordat u het project bouwt en uitvoert.
Conclusie
De komst van Swift naar het open-source netwerk heeft geleid tot een push voor Swift-oplossingen die verder gaan dan clienttoepassingen, waarbij back-end-serverframeworks in de volgende buitenwijken veranderen. Gedreven door drie prominente projecten: Vapor van Qutheory, IBM's Kitura en Perfect. Server-side Swift heeft iOS- (en macOS-) ontwikkelaars in staat gesteld full-stack ontwikkelaars te worden. Dit kan de afhankelijkheid van Node.js, PHP of .NET back-end ontwikkelaars teniet doen. Server-side Swift stelt groepen bovendien in staat om hun back-end te beheren zonder afhankelijk te zijn van mobiele back-end-as-a-server-oplossingen zoals Firebase of CloudKit.
Server-side Swift is niet voor iedereen weggelegd, je moet afrekenen hoeveel controle je nodig hebt voor je back-end, en of het zinvol is om je eigen te rollen. Bovendien heb ik niet geprobeerd u te vertellen welke Swift-oplossing aan de serverzijde ideaal is. Ontwikkelaars zijn ongetwijfeld geruïneerd bij het nemen van een beslissing, en elk van de drie geeft een unieke en volwassen kijk en is het waard om mee te experimenteren. Ik raad je aan om met elk van de voorbeeldcodes te spelen, de taalstructuur te beoordelen en contact te leggen met hun specifieke gemeenschappen om te zien welke oplossing het beste bij je past.