Share
Hva du skal skapeSiden Apple først introduserte Swift som etterfølger til Objective-C, har den revolusjonert hvordan samfunnet koder iOS, macOS, watchOS og tvOS apps. Da Swift ble en åpen kildekodeplattform, åpnet den nye muligheter for språket utover mobil og applikasjoner på klientsiden. Swift ble også et server språk! I denne opplæringen lærer du hvilken server-side Swift er, og hvorfor du vil ha Swift på baksiden din.
Server-side Swift-initiativet blir presset av tre fremtredende prosjekter -Dapor by Qutheory, IBMs Kitura, og Perfect-med sikte på å la Swift-utviklere skape fullverdige back-end-tjenester. Dette vil i hovedsak omdanne slike utviklere til fullstabile utviklere, og negere behovet for tillit til Node eller PHP eller gi kontroll over en BaaS-plattform som Googles Firebase.
I denne artikkelen vil du lære alt om server-side Swift. Først skal jeg forklare hvordan server-side Swift fungerer, og så skal jeg vise deg hvordan du kommer i gang med Kitura, Damp og Perfekt rammeverk.
Swift ble først annonsert av Apple i 2014 og ble raskt et av de raskest voksende programmeringsspråket. Swift trekker seg fra mange av de beste moderne språkene, for eksempel Python, som gir eleganse og brukervennlighet. Det frigjør ingeniører fra de tekniske bøylene i Objective-C, noe som gir mer flytende og intuitivt arbeid.
I desember 2015 laget Apple en ny monumental kunngjøring og laget Swift-språket - sammen med støttende biblioteker, debugger og pakkebehandling - et åpen kildekode-prosjekt under Apache 2.0-lisensen, åpner plattformen for publikum for å lage trekkforespørsler og bidra. Skiftet fra Objective-C har ikke bare lokket de mange Objective-C-utviklerne som bidrar til App Store, men det har gjort det enklere for utviklere av all ferdigheter og bakgrunner å komme inn i Apple-økosystemet med Swift.
Imidlertid, mens Apples utviklingsverktøy historisk har gjort det enklere for utviklere å lage visuelt overbevisende og engasjerende apper for App Store, har en bemerkelsesverdig flaskehals vært at prosjekter fortsatt krever spesialiserte utviklere for å lage komplekse datadrevne applikasjoner. Så iOS og macOS-utviklere vil enten trenge hjelp av en Python, PHP eller Node-utvikler for å lage sin back-end-database eller hente opp ferdighetene selv, noe som resulterer i en betydelig tyngre arbeidsbelastning for å fullføre prosjektmålene sine.
Selv om back-end-as-a-service (BaaS) er kommet for å redde iOS-utviklere, med no-code back-end-løsninger som Googles Firebase og Apples egen CloudKit som lindrer kompleksiteten i back-end, mange lag og prosjekter krever mer. Dette er hvor server-side Swift kommer inn, slik at du kan lage en fullverdig multi-threaded back-end server som er åpen og uendelig konfigurerbar.
Server-side Swift lar deg velge hvordan du verten din back-end-server, enten med AWS, RackSpace eller dine egne fysiske servere. Du kan også velge hvordan du laster balanse serverne dine (f.eks. Via populære serverløsninger som NGINX) og hvordan du kan fortsette dataene dine i en database (det være seg NoSQL-løsninger som MongoDB eller tradisjonelle databaser som Postgres, MySQL eller Oracle) . Ikke bare det, men du er aldri bundet til en komponentløsning - du kan bytte opp uten å påvirke hele app-kodebase.
Poenget er at ved å velge en open-source server-side Swift løsning som Dapor by Qutheory, IBMs Kitura eller Perfect, kan du dra nytte av et stort utvalg av plugins som lar deg konfigurere bakenden din akkurat slik du vil det, bruk av ditt eksisterende lags ferdighetssett i Swift å gjøre det.
Server-side Swift lyder helt sikkert overbevisende, men hvilket rammeverk passer deg? Deretter tar vi en titt på hverandre, og starter med Kitura.
Fra og med Kitura har du en plattform som ble opprinnelig utgitt i februar 2016 og ble fremtredende senere samme år på Apples WWDC, som representerte IBMs foray til å støtte server-side web med Swift, som da ble satt til overgang fra Apples hender til åpen kildekode..
Generelt sett er Kitura fokusert på konvensjon over konfigurasjon: den bygger ditt første prosjekt ut med stubber, før du velger de spesifikke rammeverkene og bibliotekene du ønsker å bygge. Kitura s autentiseringsmekanisme støttes av sin egen Kitura-Credentials mellomvare rammeverk, slik at du kan velge mellom et smorgasbord av godkjenningsmekanismer, fra det tradisjonelle brukernavnet / passordet til sosialmedia-logg og føderert autentisering, ved hjelp av OpenID som håndterer JSON Web Tokens (JWT ).
Kituras database ORM-løsning drives av Kuery for å forklare kompleksiteten i å håndtere SQL direkte, og støtter felles relasjonsdatabaser som MySQL, SQLite og PostgreSQL, samt andre databaseløsninger, inkludert NoSQL-databaser, gjennom de forskjellige andre kompatible pluginene..
Kitura gir også andre nyttige plugins for ting som HTML templating, ved hjelp av populære plugins som Stencil og Markdown. Kommer fra IBM, tjener-side rammeverket drar også fordel av intim tilkobling med IBM Watson APIer, samt gir native macOS støtte for å integrere direkte inn i Bluemix cloud-plattformen. Dette gir et ekstra alternativ til din disposisjon, sammen med dine andre tradisjonelle distribusjonsalternativer på tvers av Linux / Unix og macOS servere.
Selv om plattformen sikkert gir et unikt sett med funksjoner - fra Kuery til evnen til å integrere med de ulike IBM API-bibliotekene - har det ikke fellesskapsløpet som Vapor har. Vedtak Kitura krever å sette pris på og omfavne sine egne ikke-konvensjonelle måter å gjøre ting på, fra hvordan Kuery opererer til sine autentiseringsmekanismer. Men da det støttes av et stort selskap med fokus på bedriften, er det noen fremtidssikringsforsikringer bygget inn.
Den raskeste måten å komme i gang på er å bruke Kitura kommandolinjegrensesnitt (CLI), støttet på både macOS og Linux. Bruk det populære pakkehåndteringsverktøyet Homebrew, installer Kitura og Kitura CLI ved å skrive inn følgende:
$ bryg trykk ibm-swift / kitura $ brew install kitura
I en tom mappe som du vil bruke som prosjekt, kjør følgende for å initialisere prosjektet ditt:
$ kitura init
Når det er gjort å generere skjelett søknad, vil du legge merke til et nytt prosjekt som heter HelloKitura.xcodeproject. Du kan lære mer om prosjektgenerering ved å henvise til Kituras offisielle dokumentasjon. Du kan åpne det nylig genererte prosjektet i Xcode og redigere den primære applikasjonsklassen, Application.swift, å håndtere alle samtaler til serverens rot http: // localhost: 8080 / URL:
Accentsconagua
// Håndter HTTP GET-forespørsler til "/" router.get ("/") request, response, neste i response.send ("Hello, World!") Neste ()Kodestykket ovenfor svarer ved å returnere den klassiske Hei Verden!. Før du endelig kan kjøre prosjektet, endrer du Xcode-ordningen for å peke på HelloKitura (ditt aktive prosjekt), og sparke prosjektet ved å trykke Kommando-R. Mens serveren din kjører, går du til en nettleser etter eget valg http: // localhost: 8080 og du bør se hei verdens tekst i nettleseren din.
Ta en titt på følgende lenker for mer informasjon om Kitura.
Utgitt noen måneder senere enn Kitura, i september 2016, er Damp av Qutheory allment ansett som den mest populære når det gjelder fellesskapsstørrelse og antall plugins. Den er bygget på toppen av Apples Swift-nine-rammeverk, noe som gjør det til et ekte ytelses kraftverk. I motsetning til Kitura og andre plattformer, som ikke er bygget rent i Swift, men heller på Node.js eller andre mellomliggende parsere, slår Damp seg fra noen av disse avhengighetene til å levere en Swift-parser og gir klare og lesbare APIer.
Damp gir omfattende støtte til databaser for SQL-leverandører som MySQL og PostgreSQL, samt NoSQL-leverandører som Redis og MongoDB, som Kitura. Mens Kitura har sin egen Kuery ORM-løsning, bruker Damp Fluent ORM til å støtte databasene jeg nettopp nevnte, noe som gjør det relativt enkelt å utvide ORM til andre tredjeparts databaseleverandører. Damp skiller seg fra de andre rammene i Native Support's Push Notification Service, samt støtter SMTP for å presse e-postvarsler.
Mens Kitura implementerer sitt eget autentiseringsramme, har Vapor Stormpaths Turnstile-godkjenningsbibliotek bakt inn i det norske. Som Kitura støtter plattformen også mustasjen og Markdown-maler, samt sitt eget Swift-native uttrykksfulle templerende språk, Leaf. Damp kommer også med sin egen CLI-motor som de andre server-side Swift-rammene, med muligheten til å forlenge programkommandolinjeparametrene med egendefinerte flagg.
For å komme i gang med Vapor, starter du ved å installere Vapor-verktøykassen, som består av alle bibliotekets avhengigheter og CLI-verktøyet. Installer den med Homebrew ved å skrive inn følgende i terminalen:
$ bryg installere damp / trykk / damp
Når installasjonen er fullført, kan du bekrefte at Vapor har installert vellykket ved å skrive damp-hjelp. For å opprette et prosjekt skriver du inn følgende, og erstatter ditt eget prosjektnavn:
$ damp ny
Dampmotoren vil bygge en mappestruktur som ligner på følgende:
. ├── Offentlig ├── Kilder │ ├── App │ │ ├── Controllers │ │ ├── Modeller │ │ ├── boot.swift │ │ ├── configure.swift │ │ └── routes.swift │ └── Kjør │ └── main.swift ├── Test │ └── AppTests └── Package.swift
For å faktisk lage et Xcode-prosjekt, må du også eksplisitt skrive inn følgende kommando, inne i prosjektmappen:
$ damp xcode
Endelig, for å bygge og kjøre prosjektet ditt, velg fra Xcode Løpe ordningen samt distribusjonsmålingsenheten til Min Mac, og trykk deretter på Løpe knappen som du ville gjøre for noe annet Xcode-prosjekt. Forutsatt at Xcode-prosjektet ikke støter på noen feil, bør du se følgende bekreftelsesmelding i terminalen:
Server starter på http: // localhost: 8080
Gå videre og skriv inn nettadressen i din valgte nettleser, og du bør se at programmet kjører.
Ta en titt på følgende lenker for mer informasjon.
Endelig ser vi på Perfect by PerfectlySoft, en funksjonsrik server-side plattform som Vapor og Kitura. Perfekt inkluderer de samme standardklokkene og fløyter du vil finne på de forrige leverandørene, fra å templere med mustasje eller Markdown til nettverk med nettkontakter, samt Apple Push Notification og SMTP.
Som de andre serverplatformene har Perfect en egen ORM-implementering, StORM-plattformen (Perfect Storm), som gir opprinnelig støtte til MySQL, PostgreSQL og andre fremtredende databaser, samt MongoDB, Redis og andre NoSQL-løsninger. En bemerkelsesverdig forsømmelse fra Perfect er en CLI, men rammen utgjør dette med en innfødt macOS-app.
Som Vapor, Perfect har også Turnstile baket inn for å drive sin autentiseringsmekanisme, utvidet til å samhandle med StORM mer intimt. Et annet skille som denne løsningen har over de andre er i mange av de innfødte verktøybiblioteker som den støtter, inkludert deres egen CURL-wrapper, samt verktøy for å jobbe med filer og mapper. Perfects utviklerbase er den nest største, nesten på nivå med Vapor, noe som betyr at du har et sterkt fellesskap for å bakke denne plattformen sammen med et rikt sett med pedagogiske ressurser for å gi deg selvtillit hvis du velger det.
Å komme seg opp med Perfect er veldig greit. Først klon PerfectlySoft-repoen ved å skrive inn følgende:
$ git klon https://github.com/PerfectlySoft/PerfectTemplate.git
Bygg inn prosjektet fra den klonede mappen:
$ swift build
Endelig kjør prosjektet, som vil kjøre en lokal server på adressen 0.0.0.0:8181:
.bygge / debug / PerfectTemplate
Du kan også kjøre prosjektet ditt på Xcode ved først å generere et nytt prosjekt, som følger:
$ swift pakke generere-xcodeproj
Innenfor Xcode, sørg for at ditt kjørbare mål er peket på Min Mac, før du bygger og driver prosjektet.
Ta en titt på følgende linker for mer informasjon om Perfect Framework.
Utgivelsen av Swift til open source-fellesskapet har oppmuntret et trykk for Swift-løsninger utover klientapplikasjoner, med back-end-serverrammer som neste grense. Pushed av tre fremtredende prosjekter-Damp av Qutheory, IBMs Kitura og Perfect-server-side Swift har gjort det mulig for iOS (og macOS) ingeniører å bli fullstabile utviklere. Dette kan negere avhengigheten av Node.js, PHP eller .NET back-end ingeniører. Server-side Swift gir også lag muligheten til å kontrollere sin back-end uten å måtte stole på mobile back-end-as-a-service løsninger som Firebase eller CloudKit.
Server-side Swift er ikke for alle: du må bestemme hvor mye kontroll du trenger for din back-end, og om det gir mening for deg å rulle din egen. Også, jeg forsøkte ikke å fortelle deg hvilken server-side Swift løsning er best. Utviklere er absolutt bortskjemt for valg, og alle tre gir en unik og moden takk og er verdt å eksperimentere med. Jeg vil oppfordre deg til å leke med hver av prøvekodene, evaluere syntaksen, og engasjere seg med deres respektive lokalsamfunn for å se hvilken løsning som passer deg best.
