Dostojevskij
Medlem
Hvorfor kan man ikke like gjerne gjøre dette i f.eks. phpmyadmin?
Front-end og back-end
- Trådstarter Dostojevskij
- Startdato
Hvorfor kan man ikke like gjerne gjøre dette i f.eks. phpmyadmin?
xdex
Medlem
Fordi det er langt bedre kontroll, og det gjør testing til en lek! Scenario kan jo være at du jobber hjemme, og på jobb. Da trenger du bare kjøre en kommando, så er databasen og alt på plass. Det er også utrolig lett og endre tabeller etc underveis, dersom det er behov for det.
Du kan altså spare masse tid!
Dostojevskij
Medlem
Det er ikke noe i veien for å gjøre dette med en helt vanlig infoside? Så kan man lage en helt egen versjon på f.eks. mobile.domene.no. Det er kanskje ikke så hensiktsmessig, men kunne vært morsomt bare for å prøve å lage et API.
Dostojevskij
Medlem
Jepp, sjekker ut dette Angular-opplegget nå, og det virker ikke så vanskelig. Det vil ikke være noen problemer ved å kombinere dette med JQuery og Ajax?
xdex
Medlem
Null problem, så lenge det ikke er snakk om mange sanntidsoppdateringer, chat, notifikasjoner osv.
Dostojevskij
Medlem
Hm, jeg er faktisk ikke helt sikker. Planen er etterhvert å lage en slags rss reader, har du forslag til hva jeg bør bruke da?
hansson
Langveisfarende
Burde være unødvendig å kombinere med jQuery, da alt jQuery gjør, gjøres like bra av Angular. Angular er strukturert på en mye smartere måte enn jQuery, slik at når man sammenligner de to vil man se at jQuery nå er en utdatert teknologi.
xdex
Medlem
Hvis du skal kjøre mange sanntids operasjoner, ville jeg nok sett meg til NodeJS, mange av de store aktørene har gått over til NodeJS (eksempler: paypal, ebay etc) . Som sagt, så kan du kombinere, ved å kjøre to servere, og knytte alt sammen, men dette blir for mye å gå inn på. Dersom du uansett bare skal ha en RSS reader, holder det helt sikkert å kombinere site-refresh og enkle spørringer hvert 10minutt osv, men dette vil altså ikke være sanntids, bare nesten.
Skal du sjekke om det er noe nytt hvert sekund, kan du jo tenke deg selv hvordan dette vil bli med ajax, når hundrevis av personer er pålogget på samme tid.
adeneo
Medlem
For det første, du bør generelt sett ikke rote inn jQuery i Angular, det er ikke noe i veien for å gjøre det, men du trenger normalt ikke, Angular har uansett jQlite innebygget.
Dersom Angular skal brukes, bør dette leses først
For det andre, Angular er djevelens verk, det vil si, det er egentlig Google's verk (same same), men det lar deg skrive en haug med ugyldig HTML som byttes ut med javascript underveis, som etter min mening er dustete, men de fleste er visst uenig med meg og synes Angular er helt topp.
Personlig er jeg fan av å skrive i språk nettleseren forstår, ikke alt annet ræl.
Angular har sin egen spesielle måte å gjøre ting på, og er nesten som å lære et nytt språk, kan du allerede javascript og ikke har planer om å lage en "en-sides Angular app" eller noe slikt, så har det lite for seg å bruke Angular, ting er normalt enklere uten den elendigheten.
Spørsmålet er egentlig hva du kan, og hva du skal lage ?
Kan du PHP, så er Laravel sikkert fine greier, det er et MVC rammeverk, og du bør jo nødvendigvis lage både modeller og views når du først er i gang, dette med back-end og front-end er litt misvisende, de henger jo nødvendigvis ganske tett sammen og bør generelt sett lages samtidig for best resultat, i det minste etter min mening.
Skal du lage en enkel nettside som bruker data fra en database e.l, så er det også lite hensiktsmessig å sette opp en REST API for å levere de dataene, bare hent de direkte på den måten som passer i stedet, API'er finfine greier det, men for å levere data til en enkelt nettside så er det bare å komplisere ting.
Alle system som leverer data er jo egentlig er en slags API, det jeg mener her er selvfølgelig at det ikke er nødvendig å sette opp et eget endepunkt som leverer data basert på input og slikt, det er mye enklere å bruke enkle PHP scripts som leverer du trenger, eventuelt over ajax.
Kan du ikke PHP, så er kanskje ikke Laravel stedet å begynne, hvor klasser, MVC og en rekke til dels kompliserte funksjoner brukes til så å si alt.
Det er mange fancy ord man kan slenge ut, men det er jo en gang sånn at skal man lage nettsider, så er det viktigste å kunne HTML, CSS og JavaScript, og kanskje litt vanlig "procedural" PHP, altså ikke OOP til å begynne med, man bør lære å krabbe før man kan gå, og da blir det også enkelt å sette opp enkle nettsider, og back-end og front-end blir nesten same shit, alt henger sammen med alt uansett.
Du kan selvfølgelig gå rett på Laravel, sette opp API'er og det ene med det andre, og la en eller annen stakkar ta seg av å nøste elendigheten sammen i "front-end", men det er som regel et helvete å liksom skulle lage en nettside basert på ymse data noen har laget et system for i PHP, og en tegning fra Photoshop, og det blir sannsynligvis billigere å bare få noen til å lage hele greiene, enn at de skal finne ut av ditt rot i etterkant.
Eh, nei !
Dersom Angular skal brukes, bør dette leses først
For det andre, Angular er djevelens verk, det vil si, det er egentlig Google's verk (same same), men det lar deg skrive en haug med ugyldig HTML som byttes ut med javascript underveis, som etter min mening er dustete, men de fleste er visst uenig med meg og synes Angular er helt topp.
Personlig er jeg fan av å skrive i språk nettleseren forstår, ikke alt annet ræl.
Angular har sin egen spesielle måte å gjøre ting på, og er nesten som å lære et nytt språk, kan du allerede javascript og ikke har planer om å lage en "en-sides Angular app" eller noe slikt, så har det lite for seg å bruke Angular, ting er normalt enklere uten den elendigheten.
Spørsmålet er egentlig hva du kan, og hva du skal lage ?
Kan du PHP, så er Laravel sikkert fine greier, det er et MVC rammeverk, og du bør jo nødvendigvis lage både modeller og views når du først er i gang, dette med back-end og front-end er litt misvisende, de henger jo nødvendigvis ganske tett sammen og bør generelt sett lages samtidig for best resultat, i det minste etter min mening.
Skal du lage en enkel nettside som bruker data fra en database e.l, så er det også lite hensiktsmessig å sette opp en REST API for å levere de dataene, bare hent de direkte på den måten som passer i stedet, API'er finfine greier det, men for å levere data til en enkelt nettside så er det bare å komplisere ting.
Alle system som leverer data er jo egentlig er en slags API, det jeg mener her er selvfølgelig at det ikke er nødvendig å sette opp et eget endepunkt som leverer data basert på input og slikt, det er mye enklere å bruke enkle PHP scripts som leverer du trenger, eventuelt over ajax.
Kan du ikke PHP, så er kanskje ikke Laravel stedet å begynne, hvor klasser, MVC og en rekke til dels kompliserte funksjoner brukes til så å si alt.
Det er mange fancy ord man kan slenge ut, men det er jo en gang sånn at skal man lage nettsider, så er det viktigste å kunne HTML, CSS og JavaScript, og kanskje litt vanlig "procedural" PHP, altså ikke OOP til å begynne med, man bør lære å krabbe før man kan gå, og da blir det også enkelt å sette opp enkle nettsider, og back-end og front-end blir nesten same shit, alt henger sammen med alt uansett.
Du kan selvfølgelig gå rett på Laravel, sette opp API'er og det ene med det andre, og la en eller annen stakkar ta seg av å nøste elendigheten sammen i "front-end", men det er som regel et helvete å liksom skulle lage en nettside basert på ymse data noen har laget et system for i PHP, og en tegning fra Photoshop, og det blir sannsynligvis billigere å bare få noen til å lage hele greiene, enn at de skal finne ut av ditt rot i etterkant.
Eh, nei !
Han har jo sagt at han planlegger en mobil app, og når han gjør det så er det hensiktsmessig å gå for api ruten, for da sparer man seg for arbeid senere.
Det er heller ikke til å unngå at rest api og et js frontend, som ikke nødvendigvis må være Angular, er en teknisk overlegen løsning på flere sentrale punkt, og oppnår flere ting utover å bare komplisere:
-Mindre bruk av HW ressurser, bedre ytelse
-Mindre båndbreddebruk
-Bedre skaleringsevne
-Enklere integrasjoner
-Ryddigere kodebase
-Byggekloss-prinsippet. Hvis han skulle finne ut at han må bytte backend til f.eks node.js, så kan han gjøre det uten å røre på frontenden.
Så mye mer komplisert og tidkrevende er det ikke å implementere heller. Har du laget en ajax callback så er rest apier bare en naturlig forlengelse av det, så i min mening er det et åpenbart valg.
Det er heller ikke til å unngå at rest api og et js frontend, som ikke nødvendigvis må være Angular, er en teknisk overlegen løsning på flere sentrale punkt, og oppnår flere ting utover å bare komplisere:
-Mindre bruk av HW ressurser, bedre ytelse
-Mindre båndbreddebruk
-Bedre skaleringsevne
-Enklere integrasjoner
-Ryddigere kodebase
-Byggekloss-prinsippet. Hvis han skulle finne ut at han må bytte backend til f.eks node.js, så kan han gjøre det uten å røre på frontenden.
Så mye mer komplisert og tidkrevende er det ikke å implementere heller. Har du laget en ajax callback så er rest apier bare en naturlig forlengelse av det, så i min mening er det et åpenbart valg.
Dostojevskij
Medlem
Jeg kan jo ting som HTML, CSS, JavaScript og PHP, og har jobbet med Laravel noen uker nå og liker det veldig godt, så det er noe jeg kommer til å fortsette med. Jeg skjønner at det ikke er nødvendig å lage et API for en enkel infoside - som du korrekt nok sier man kun trenger HTML, CSS og JavaScript for lage. Men jeg og et par til planlegger et litt større prosjekt, som blant annet inkluderer en app, og da lurer vi litt på hvordan vi skal legge det opp og fordele arbeidet. Jeg synes da det virker veldig ryddig (Og lærerikt) å lage et API.
adeneo
Medlem
Hvis du trenger en RESTful API, så setter du selvfølgelig opp det, og native apps og nettsider som trenger samme data kan være en god grunn til å benytte en REST API.
Men, det er jo ikke bare å slenge sammen noe der heller, du må jo for eksempel vite hvorvidt du trenger å omgå same-origin policien, generelt er ikke det noe problem med native apps, men for nettlesere kan det være det, og det bør være autentifikasjon osv. dersom det er bare din app som skal bruke API'en.
Skal du bruke en database så gjelder det samme som alltid, du må passe på at det ikke er mulig å benytte API'en til å ta kontroll over databasen din.
Skal du bruke Node så må du stort sett kjøre NGINX foran, sette opp Forever og cron jobs osv. slik at API'en starter opp igjen dersom serveren reboot'er eller går ned (Node starter ikke automatisk), samt at det er uhyggelig mye lettere å gjøre feil i Node som åpner opp for sikkerhetsproblemer.
Så er spørsmålet om du skal bruke OData, OASIS eller andre standarder, returnere JSON, eventuelt JSONP dersom du trenger det, hvis du i det hele tatt trenger å følge noen standard, det kommer jo an på om andre skal benytte API'en.
Det er ikke bare å bare å sette opp en API heller, i det minste ikke hvis man skal gjøre det skikkelig, fordelen med Node er jo at det er enkelt å lese RSS, hente data og slikt, med feedparser og request så er det så enkelt som
Legg merke til at jeg ikke har tatt med error handling i det hele tatt, som er et helt eget kapittel i Node.
Men, det er jo ikke bare å slenge sammen noe der heller, du må jo for eksempel vite hvorvidt du trenger å omgå same-origin policien, generelt er ikke det noe problem med native apps, men for nettlesere kan det være det, og det bør være autentifikasjon osv. dersom det er bare din app som skal bruke API'en.
Skal du bruke en database så gjelder det samme som alltid, du må passe på at det ikke er mulig å benytte API'en til å ta kontroll over databasen din.
Skal du bruke Node så må du stort sett kjøre NGINX foran, sette opp Forever og cron jobs osv. slik at API'en starter opp igjen dersom serveren reboot'er eller går ned (Node starter ikke automatisk), samt at det er uhyggelig mye lettere å gjøre feil i Node som åpner opp for sikkerhetsproblemer.
Så er spørsmålet om du skal bruke OData, OASIS eller andre standarder, returnere JSON, eventuelt JSONP dersom du trenger det, hvis du i det hele tatt trenger å følge noen standard, det kommer jo an på om andre skal benytte API'en.
Det er ikke bare å bare å sette opp en API heller, i det minste ikke hvis man skal gjøre det skikkelig, fordelen med Node er jo at det er enkelt å lese RSS, hente data og slikt, med feedparser og request så er det så enkelt som
PHP:
var request = require('request'),
FeedParser = require('feedparser');
function hentRSS(url, callback) {
var RSSreq = request({url : url, encoding : null}),
feedparser = new FeedParser();
RSSreq.on('response', function (res) {
this.pipe(feedparser);
});
feedparser.on('readable', function() {
callback(this.read());
});
}
setInterval(function() {
hentRSS( 'http://www.blogg.no/tantepose.rss', function(rss) {
// rss tilgjengig som "object" her, ferdig parset og klart til bruk !
});
}, 1000 * 60 * 5); // hvert femte minuttLegg merke til at jeg ikke har tatt med error handling i det hele tatt, som er et helt eget kapittel i Node.