On tarpeetonta mainita Node.js: n kasvavaa suosiota sovelluskehityksessä. eBay on toiminut tuotantosolmun sovellusliittymäpalvelun kanssa vuodesta 2011. PayPal rakentaa aktiivisesti etupäänsä Solmessa. Walmartin mobiilisivustosta on tullut suurin Node-sovellus liikenteen kannalta. Kiitospäivänä viikonloppuna vuonna 2014, Walmart-palvelimet käsittelivät 1,5 miljardia pyyntöä , Joista 70 prosenttia toimitettiin matkapuhelimen kautta ja jonka tarjoaa Node.js. Kehityspuolella Node-paketinhallinta ( merenpinnan yläpuolella ) kasvaa edelleen nopeasti ylittäen äskettäin 150 000 isännöityä moduulia.
Sillä aikaa Rubyllä on kiskot ja Python on Django, solmun hallitsevaa sovelluskehityskehystä ei ole vielä luotu. Mutta on voimakas kilpailija, joka saa höyryä: Silmukka , avoimen lähdekoodin API-kehys, jonka rakensi San Mateo, Kalifornia Vahva silmukka . StrongLoop on tärkeä avustaja uusimpaan Solmuversio , puhumattakaan pitkäaikaisista ylläpitäjistä Ilmaista , yksi suosituimmista solmujen kehyksistä.
Katsotaanpa tarkemmin LoopBackia ja sen ominaisuuksia muuttamalla kaikki käytäntöön ja rakentamalla esimerkkisovellus.
LoopBack on kehys luoden sovellusliittymiä ja yhdistää ne taustalla oleviin tietolähteisiin. Expressin päälle rakennettu se voi ottaa tietomallin määritelmän ja luoda helposti täysin toimivan end-to-end REST -sovellusliittymän, jonka kuka tahansa asiakas voi kutsua.
LoopBackissa on sisäänrakennettu asiakas, API Explorer . Käytämme tätä, koska sen avulla on helpompaa nähdä työmme tulokset ja jotta esimerkissämme voidaan keskittyä itse API: n rakentamiseen.
Tarvitset tietysti koneellesi asennetun solmun, jotta voit seurata sitä. Hanki se tässä . npm tulee sen mukana, joten voit asentaa tarvittavat paketit helposti. Aloitetaan.
Sovelluksemme hallitsee ihmisiä, jotka haluavat lahjoittaa lahjoja tai asioita, joita he eivät enää tarvitse, jollekin, joka saattaa tarvita niitä. Joten käyttäjät ovat lahjoittajia ja vastaanottajia. Lahjoittaja voi luoda uuden lahjan ja nähdä luettelon lahjoista. Vastaanottaja näkee luettelon kaikkien käyttäjien lahjoista ja voi vaatia mitä tahansa lunastamatonta. Tietysti voisimme rakentaa lahjoittajat ja vastaanottajat erillisinä rooleina samaan kokonaisuuteen (käyttäjä), mutta yritetään erottaa ne, jotta voimme nähdä, kuinka rakentaa suhteita LoopBackiin. Tämän uraauurtavan sovelluksen nimi on Antaa jonkun .
Asenna StrongLoop-komentorivityökalut npm: n kautta:
$ npm install -g strongloop
Suorita sitten LoopBackin sovellusgeneraattori:
$ slc loopback _-----_ | | .--------------------------. |--(o)--| | Let's create a LoopBack | `---------´ | application! | ( _´U`_ ) '--------------------------' /___A___ | ~ | __'.___.'__ ´ ` |° ´ Y ` ? What's the name of your application? Givesomebody
Lisätään malli. Ensimmäisen mallimme nimi on Lahja. LoopBack kysyy tietolähdettä ja perusluokkaa. Koska emme ole vielä määrittäneet tietolähdettä, voimme lisätä db (memory)
Perusluokka on automaattisesti luotu malliluokka, ja haluamme käyttää PersistedModel
tässä tapauksessa, koska se sisältää jo kaikki meille tavanomaiset CRUD-menetelmät. Seuraavaksi LoopBack kysyy, pitäisikö sen paljastaa malli RESTin kautta (kyllä), ja REST-palvelun nimi. Paina Enter-näppäintä käyttääksesi oletusarvoa, joka on yksinkertaisesti mallin nimen monikko (tapauksessamme gifts
).
$ slc loopback:model ? Enter the model name: Gift ? Select the data-source to attach Gift to: (Use arrow keys) ❯ db (memory) ? Select model's base class: (Use arrow keys) Model ❯ PersistedModel ? Expose Gift via the REST API? (Y/n) Yes ? Custom plural form (used to build REST URL):
Lopuksi annamme ominaisuuksien nimet, niiden tietotyypit ja vaaditut / ei vaaditut liput. Lahja on name
ja description
ominaisuudet:
Let's add some Gift properties now. Enter an empty property name when done. ? Property name: name invoke loopback:property ? Property type: (Use arrow keys) ❯ string ? Required? (y/N)Yes
Syötä tyhjä ominaisuuden nimi osoittamaan, että olet määrittänyt ominaisuudet.
Malligeneraattori luo kaksi tiedostoa, jotka määrittävät mallin sovelluksen common/models
: gift.json
ja gift.js
. JSON-tiedosto määrittää kaikki olion metatiedot: ominaisuudet, suhteet, validoinnit, roolit ja menetelmien nimet. JavaScript-tiedostoa käytetään lisäkäyttäytymisen määrittelemiseen ja etäkoukkujen kutsumiseen ennen tai jälkeen tiettyjen toimintojen (esim. Luominen, päivittäminen tai poistaminen).
Kaksi muuta mallikokonaisuutta ovat luovuttaja- ja vastaanottajamallimme. Voimme luoda ne samalla prosessilla, paitsi että nyt laitetaan User
perusluokan. Se antaa meille joitain ominaisuuksia, kuten username
, password
, email
ulos laatikosta. Voimme lisätä esimerkiksi nimen ja maan, jotta meillä olisi täydellinen kokonaisuus. Vastaanottimelle haluamme lisätä myös toimitusosoitteen.
Katsotaanpa luodun projektin rakennetta:
Kolme päähakemistoa ovat: - /server
- Sisältää solmuohjelmakoodeja ja määritystiedostoja. - /client
- Sisältää .js, .html, .css ja kaikki muut staattiset tiedostot. - /common
- Tämä kansio on yhteinen sekä palvelimelle että asiakkaalle. Mallitiedostot menevät tänne.
Tässä on yksityiskohtainen erittely kunkin hakemiston sisällöstä LoopBack-dokumentaatio :
Tiedosto tai hakemisto | Kuvaus | Kuinka päästä koodiksi |
---|---|---|
Ylätason sovellushakemisto | ||
package.json | Normaali npm-pakettimääritys. Katso package.json | N / A |
/ palvelimen hakemisto - Solmu-sovellustiedostot | ||
server.js | Sovelluksen päätiedosto. | N / A |
config.json | Sovellusasetukset. Katso config.json . | app.get('setting-name') |
datasources.json | Tietolähteen määritystiedosto. Katso datasources.json .Katso esimerkiksi Luo uusi tietolähde . | app.datasources['datasource-name'] |
model-config.json | Mallin kokoonpanotiedosto. Katso malli-config.json .Katso lisätietoja Mallien yhdistäminen tietolähteisiin . | N / A |
middleware.json | Middleware-määritystiedosto. Katso lisätietoja Väliohjelman määrittely . | N / A |
/boot hakemistoon | Lisää komentosarjat alustuksen ja asennuksen suorittamiseksi. Katso käynnistysskriptejä . | Komentosarjat suoritetaan automaattisesti aakkosjärjestyksessä. |
/ asiakashakemisto - asiakassovellustiedostot | ||
README.md | LoopBack-generaattorit luovat tyhjän README-tiedoston merkintämuodossa. | N / A |
Muu | Lisää HTML-, CSS-, asiakas-JavaScript-tiedostosi. | |
/ common directory - jaetut sovellustiedostot | ||
/models hakemistoon | Mukautetut mallitiedostot:
| Solmu: myModel = app.models.myModelName |
Esimerkissämme meillä on muutama tärkeä suhde mallinnettavaksi. Lahjoittaja voi lahjoittaa monia lahjoja, mikä antaa yhteyden Lahjoittajalla on monia lahjoja . Vastaanotin voi myös vastaanottaa monia lahjoja, joten meillä on myös suhde Vastaanottimessa on monia lahjoja . Toisella puolella, Lahja kuuluu luovuttajalle , ja voi myös kuuluvat vastaanottimeen jos vastaanottaja päättää hyväksyä sen. Laitetaan tämä LoopBack-kielelle.
$ slc loopback:relation ? Select the model to create the relationship from: Donor ? Relation type: has many ? Choose a model to create a relationship with: Gift ? Enter the property name for the relation: gifts ? Optionally enter a custom foreign key: ? Require a through model? No
Huomaa, että läpimallia ei ole; meillä on vain viittaus lahjaan.
Jos toistamme yllä olevan menettelyn Vastaanottimelle ja lisätään kaksi kuuluu suhteet lahjaan, toteutamme mallisuunnittelumme takapuolella. LoopBack päivittää mallien JSON-tiedostot automaattisesti ilmaisemaan tarkalleen mitä teimme juuri näiden yksinkertaisten valintaikkunoiden avulla:
// common/models/donor.json ... 'relations': { 'gifts': { 'type': 'hasMany', 'model': 'Gift', 'foreignKey': '' } }, ...
Katsotaan nyt, kuinka liitetään todellinen tietolähde kaikkien sovellustietojemme tallentamiseen. Tämän esimerkin tarkoituksiin käytämme MongoDB , mutta LoopBackilla on moduulit yhteyden muodostamiseksi Oraclen, MySQL: n, PostgreSQL: n, Rediksen ja SQL Serverin kanssa.
Asenna ensin liitin:
$ npm install --save loopback-connector-mongodb
Lisää sitten tietolähde projektiisi:
$ slc loopback:datasource ? Enter the data-source name: givesomebody ? Select the connector for givesomebody: MongoDB (supported by StrongLoop)
Seuraava vaihe on määrittää tietolähteesi server/datasources.json
. Käytä tätä kokoonpanoa paikalliselle MongoDB-palvelimelle:
... 'givesomebody': { 'name': 'givesomebody', 'connector': 'mongodb', 'host': 'localhost', 'port': 27017, 'database': 'givesomebody', 'username': '', 'password': '' } ...
Avaa lopuksi server/model-config.json
ja muuta datasource
kaikille entiteeteille, jotka haluamme säilyttää tietokannassa: 'givesomebody'
{ ... 'User': { 'dataSource': 'givesomebody' }, 'AccessToken': { 'dataSource': 'givesomebody', 'public': false }, 'ACL': { 'dataSource': 'givesomebody', 'public': false }, 'RoleMapping': { 'dataSource': 'givesomebody', 'public': false }, 'Role': { 'dataSource': 'givesomebody', 'public': false }, 'Gift': { 'dataSource': 'givesomebody', 'public': true }, 'Donor': { 'dataSource': 'givesomebody', 'public': true }, 'Receiver': { 'dataSource': 'givesomebody', 'public': true } }
On aika nähdä, mitä olemme rakentaneet tähän mennessä! Käytämme mahtavaa sisäänrakennettua työkalua, API Explorer , jota voidaan käyttää juuri luomamme palvelun asiakkaana. Yritetään kokeilla REST-sovellusliittymä puhelut.
Käynnistä MongoDB erillisessä ikkunassa seuraavasti:
$ mongod
Suorita sovellus seuraavilla tavoilla:
$ node .
Siirry selaimessasi kohtaan http://localhost:3000/explorer/
. Näet entiteettisi käytettävissä olevien toimintojen luettelon kanssa. Yritä lisätä yksi lahjoittaja POSTilla /Donors
soittaa puhelimella.
API Explorer on hyvin intuitiivinen; valitse jokin näkyvistä menetelmistä, ja vastaava mallikaavio näytetään oikeassa alakulmassa. Kohdassa data
tekstialueella, on mahdollista kirjoittaa mukautettu HTTP-pyyntö. Kun pyyntö on täytetty, napsauta Kokeile-painiketta, jolloin palvelimen vastaus näkyy alla.
Kuten edellä mainittiin, yksi LoopBackin kanssa valmiiksi rakennetuista kokonaisuuksista on User-luokka. Käyttäjällä on sisäänkirjautumis- ja uloskirjautumismenetelmät, ja hänet voidaan sitoa AccessToken-entiteettiin, joka pitää tietyn käyttäjän tunnuksen. Itse asiassa täydellinen käyttäjän todennusjärjestelmä on valmis lähtemään laatikosta. Jos yritämme soittaa /Donors/login
kautta API Explorer , tässä on vastaus, jonka saamme:
{ 'id': '9Kvp4zc0rTrH7IMMeRGwTNc6IqNxpVfv7D17DEcHHsgcAf9Z36A3CnPpZJ1iGrMS', 'ttl': 1209600, 'created': '2015-05-26T01:24:41.561Z', 'userId': '' }
id
on itse asiassa AccessTokenin arvo, joka luodaan ja säilytetään tietokannassa automaattisesti. Kuten näette täällä, on mahdollista asettaa käyttöoikeustunnus ja käyttää sitä jokaisessa seuraavassa pyynnössä.
Etämenetelmä on mallin staattinen menetelmä, joka on altistettu mukautetulle REST-päätepisteelle. Etämenetelmiä voidaan käyttää toimintojen suorittamiseen, joita LoopBackin vakiomalli REST API ei tarjoa.
Laatikosta saamiemme CRUD-menetelmien lisäksi voimme lisätä niin monta mukautettua menetelmää kuin haluamme. Kaikkien heidän pitäisi mennä [model].js
tiedosto. Meidän on lisättävä tässä tapauksessa etämenetelmä lahjamalliin tarkistaaksemme, onko lahja jo varattu, ja luetteloimaan kaikki lahjat, joita ei ole varattu.
Lisää ensin malliin ylimääräinen ominaisuus nimeltä reserved
Lisää tämä vain gift.json
: n ominaisuuksiin:
... 'reserved': { 'type': 'boolean' } ...
Etämenetelmä kohdassa gift.js
pitäisi näyttää tältä:
module.exports = function(Gift) { // method which lists all free gifts Gift.listFree = function(cb) { Gift.find({ fields: { reserved: false } }, cb); }; // expose the above method through the REST Gift.remoteMethod('listFree', { returns: { arg: 'gifts', type: 'array' }, http: { path: '/list-free', verb: 'get' } }); // method to return if the gift is free Gift.isFree = function(id, cb) { var response; Gift.find({ fields: { id: id } }, function(err, gift) { if (err) return cb(err); if (gift.reserved) response = 'Sorry, the gift is reserved'; else response = 'Great, this gift can be yours'; }); cb(null, response); }; // expose the method through REST Gift.remoteMethod('isFree', { accepts: { arg: 'id', type: 'number' }, returns: { arg: 'response', type: 'string' }, http: { path: '/free', verb: 'post' } }); };
Joten saadakseen selville, onko tietty lahja saatavilla, asiakas voi nyt lähettää POST-pyynnön /api/Gifts/free
lähettämällä id
kyseisen lahjan.
Joskus on tarpeen suorittaa jokin menetelmä ennen etämenetelmää tai sen jälkeen. Voit määrittää kahdenlaisia koukkuja:
beforeRemote()
suoritetaan ennen etämenetelmää.afterRemote()
suoritetaan etämenetelmän jälkeen.Molemmissa tapauksissa annat kaksi argumenttia: merkkijono, joka vastaa etämenetelmää, johon haluat 'kytkeä' toiminnon, ja soittopyynnön. Suuri osa etäkoukkujen voimasta on, että merkkijono voi sisältää jokerimerkkejä, joten se laukaistaan millä tahansa vastaavalla menetelmällä.
Meidän tapauksessamme asetetaan koukku tulostamaan tietoja konsoliin aina kun uusi luovuttaja luodaan. Tämän saavuttamiseksi lisätään 'ennen luomista' -koukku donor.js
module.exports = function(Donor) { Donor.beforeRemote('create', function(context, donor, next) { console.log('Saving new donor with name: ', context.req.body.name); next(); }); };
Pyyntö kutsutaan annetulla context
ja next()
takaisinsoitto väliohjelmistossa (käsitellään alla) kutsutaan koukun suorituksen jälkeen.
LoopBack-sovellukset pääsevät tietoihin mallien kautta, joten tietojen käytön hallinta tarkoittaa mallien rajoitusten määrittelemistä; eli määritetään kuka tai mikä voi lukea ja kirjoittaa tietoja tai suorittaa menetelmiä malleissa. LoopBack-pääsynhallinta määräytyy kulunvalvontaluetteloiden tai ACL-luetteloiden avulla.
Annetaan kirjautumattomien lahjoittajien ja vastaanottajien tarkastella lahjoja, mutta vain kirjautuneet lahjoittajat voivat luoda ja poistaa ne.
$ slc loopback:acl
Aloitetaan kieltämällä kaikki pääsy kaikkiin päätepisteisiin.
? Select the model to apply the ACL entry to: Gift ? Select the ACL scope: All methods and properties ? Select the access type: All (match all types) ? Select the role: All users ? Select the permission to apply: Explicitly deny access
Salli seuraavaksi kaikkien lukea lahjamalleista:
$ slc loopback:acl ? Select the model to apply the ACL entry to: Gift ? Select the ACL scope: All methods and properties ? Select the access type: Read ? Select the role: All users ? Select the permission to apply: Explicitly grant access
Sitten haluamme sallia todennettujen käyttäjien luoda lahjoja:
$ slc loopback:acl ? Select the model to apply the ACL entry to: Gift ? Select the ACL scope: A single method ? Enter the method name: create ? Select the role: Any authenticated user ? Select the permission to apply: Explicitly grant access
Annetaan lopuksi lahjan omistajalle mahdollisuus tehdä muutoksia:
$ slc loopback:acl ? Select the model to apply the ACL entry to: Gift ? Select the ACL scope: All methods and properties ? Select the access type: Write ? Select the role: The user owning the object ? Select the permission to apply: Explicitly grant access
Kun tarkastelemme gift.json
, kaiken pitäisi olla paikallaan:
'acls': [ { 'accessType': '*', 'principalType': 'ROLE', 'principalId': '$everyone', 'permission': 'DENY' }, { 'accessType': 'READ', 'principalType': 'ROLE', 'principalId': '$everyone', 'permission': 'ALLOW' }, { 'accessType': 'EXECUTE', 'principalType': 'ROLE', 'principalId': '$authenticated', 'permission': 'ALLOW', 'property': 'create' } ],
Yksi tärkeä huomautus tässä: $authenticated
on ennalta määritelty rooli, joka vastaa kaikkia järjestelmän käyttäjiä (sekä lahjoittajia että vastaanottajia), mutta haluamme vain sallia lahjoittajien luoda uusia lahjoja. Siksi tarvitsemme mukautetun roolin. Koska rooli on yksi entiteetti, jonka poistamme laatikosta, voimme hyödyntää sen API-kutsua luodaksesi $authenticatedDonor
rooli käynnistystoiminnossa ja muokkaa sitten pricipalId
sisään gift.json
Sinun on luotava uusi tiedosto server/boot/script.js
ja lisättävä seuraava koodi:
Role.create({ name: 'authenticatedDonor' }, function(err, role) { if (err) return debug(err); })
RoleMapping-entiteetti kartoittaa roolit käyttäjille. Varmista, että Role ja RoleMapping ovat molemmat näkyvissä REST: n kautta. Tarkista server/model-config.json
-kohdassa, että 'public'
on asetettu arvoon true
Role-entiteettiin. Sitten donor.js
-sivulle voimme kirjoittaa 'ennen luomista' -koukun, joka kartoittaa userID
ja roleID
RoleMapping POST -sovellusliittymäkutsussa.
Väliohjelmisto sisältää toimintoja, jotka suoritetaan, kun pyyntö tehdään REST-päätepisteelle. Koska LoopBack perustuu Expressiin, se käyttää Express-väliohjelmia yhdellä lisäkonseptilla, jota kutsutaan väliohjelmistovaiheiksi. Vaiheita käytetään määrittämään selkeästi järjestys, jossa väliohjelmiston toiminnot kutsutaan.
Tässä on luettelo ennalta määritetyistä vaiheista LoopBack-asiakirjoissa:
Jokaisessa vaiheessa on kolme alivaihetta. Esimerkiksi alkuvaiheen alivaiheet ovat:
Katsotaanpa nopeasti oletusohjelmistoamme: json:
{ 'initial:before': { 'loopback#favicon': {} }, 'initial': { 'compression': {}, 'cors': { 'params': { 'origin': true, 'credentials': true, 'maxAge': 86400 } } }, 'session': { }, 'auth': { }, 'parse': { }, 'routes': { }, 'files': { }, 'final': { 'loopback#urlNotFound': {} }, 'final:after': { 'errorhandler': {} } }
Alkuvaiheessa soitamme loopback.favicon()
(loopback#favicon
on puhelun väliohjelmistotunnus). Sitten kolmannen osapuolen npm-moduulit compression
ja cors
kutsutaan (parametreilla tai ilman niitä). Viimeisessä vaiheessa meillä on vielä kaksi puhelua. urlNotFound
on LoopBack-kutsu ja errorhandler
on kolmannen osapuolen moduuli. Tämän esimerkin pitäisi osoittaa, että paljon sisäänrakennettuja puheluita voidaan käyttää aivan kuten ulkoisia npm-moduuleja. Ja tietysti voimme aina luoda oman väliohjelmiston ja kutsua heitä tämän JSON-tiedoston kautta.
loopback-boot
Lopuksi mainitaan moduuli, joka vie boot()
toiminto, joka alustaa sovelluksen. Kohdassa server/server.js
löydät seuraavan koodinpätkän, joka käynnistää sovelluksen:
boot(app, __dirname, function(err) { if (err) throw err; // start the server if `$ node server.js` if (require.main === module) app.start(); });
Tämä komentosarja etsii server/boot
-kansioon ja lataa kaikki sen löytämät skriptit aakkosjärjestyksessä. Näin ollen server/boot
: ssa voimme määrittää minkä tahansa komentosarjan, joka tulisi suorittaa alussa. Yksi esimerkki on explorer.js
, joka toimii API Explorer , asiakas, jota käytimme API: n testaamiseen.
Ennen kuin jätän sinut, haluaisin mainita StrongLoop-kaari , graafinen käyttöliittymä, jota voidaan käyttää vaihtoehtona slc
komentorivityökalut. Se sisältää myös työkaluja solmujen sovellusten rakentamiseen, profilointiin ja seurantaan. Niille, jotka eivät ole komentorivin faneja, kannattaa ehdottomasti kokeilla. StrongLoop Arc on kuitenkin poistumassa käytöstä ja sen toiminnot integroidaan IBM API Connect -kehittäjien työkalupakki .
Yleisesti ottaen LoopBack voi säästää paljon manuaalista työtä, koska saat paljon tavaraa laatikosta. Sen avulla voit keskittyä sovelluskohtaisiin ongelmiin ja liiketoimintalogiikkaan. Jos hakemuksesi on perustuu CRUD-operaatioihin ja ennalta määritettyjen entiteettien käsittely, jos olet kyllästynyt kirjoittamaan käyttäjän todennus- ja valtuutusinfrastruktuuria uudelleen, kun monet kehittäjät ovat kirjoittaneet sen ennen sinua, tai jos haluat hyödyntää kaikkia suuren verkkokehyksen etuja, kuten Express, rakenna REST-sovellusliittymäsi LoopBack voi tehdä unelmistasi totta. Se on helppo nakki!