Front End Developer vs Back End Developer - Definition og betydning i praksis

Hjemmesider og applikationer er komplekse! Knapper og billeder er kun toppen af ​​isbjerget. Med denne form for kompleksitet har du brug for folk til at styre det, men hvilke dele er frontend-udviklere og back-end-udviklere ansvarlige for?

  • De mange udviklingslag
  • Men vi er ikke alle fulde stack
  • Så hvad er forskellen mellem Front End Development og Back End Development?
  • Hvad er frontend-udvikling?
  • Hvad er Back End Development?
  • Hvor ting bliver fuzzy
  • Ressourcer at lære

De mange udviklingslag

Uanset om du arbejder på et websted eller en native iOS-app, deler alle udviklingsmiljøer et fælles tema - der er en frontend til en applikation og en back-end.

Denne linje kan blive sløret, især i betragtning af stigningen i javascript og den serverløse verden. Når værktøjet smelter sammen, undrer vi os nogle gange over, om vi er en fuld stack-udvikler.

“Fullstack” udvikler. pic.twitter.com/yfymQmJJgq

- Brian Holt (@holtbt) 24. marts 2018

Men vi er ikke alle fulde stack

Så meget som vi alle måske ønsker at være, er vi ikke alle fuld stack-udviklere. Personligt finder jeg mig i stand til at være produktiv i den bageste ende af en applikation, men det er ikke min styrke, og jeg foretrækker meget at være hovedet ned og oprette brugergrænseflader.

Og nogle mennesker er det modsatte, hvor de er stærkest med at opbygge API'er i den bageste ende af en applikation, og selvom de kan opbygge et brugergrænseflade, kan det være mere en prototype-lignende oplevelse end en konkret anvendelse.

Så hvad er forskellen mellem Front End Development og Back End Development?

Selvom du er en fuld stack-udvikler, betyder det ikke, at der ikke er en ansvarsfordeling.

Så hvordan ser de ud?

Hvad er frontend-udvikling?

Den forreste ende af en applikation henviser typisk til det lag, der repræsenterer brugergrænsefladen (brugergrænsefladen). Dette kan omfatte alt fra et statisk sted med HTML og CSS til en fuld React-app, der driver UI.

Hvordan så Front End Development traditionelt ud?

Javascript styrer i øjeblikket frontend-nettet, men det var ikke altid tilfældet. Mens det kunne have været brugt til at tilføje små bits af interaktion til et websted, blev frontendene typisk gengivet ved hjælp af skabelonsprog på serversiden som rammedrevet PHP og Template Toolkit (Perl).

Dette voksede til at være super populært i praksis med hjemmevoksede rammer eller værktøjer som Wordpress, der brugte PHP til at drive et massivt samfund af udviklere, der byggede deres hjemmesider med disse værktøjer.

Den måde, det fungerede på, var skabelonsproget i stand til at få sine data direkte fra serveren, da de blev gengivet. Når en browser anmodede om siden direkte fra oprindelsen (selve serveren), uanset hvilke data skabelonen har brug for, ville applikationslogikken give på det tidspunkt.

Nogle af de mere traditionelle frontendeværktøjer inkluderer:

  • Biblioteker som jQuery eller MooTools
  • Webstedsrammer som Wordpress
  • Almindelig CSS
  • Rigelig brug af tabelelementer

Men som tiden gik, blev javascript ved med at blive mere modent som sprog, og browsere blev stadig mere magtfulde, hvilket førte til ideen om, at vi kunne flytte mere af det arbejde til browseren for at opbygge hurtigere og mere interaktive oplevelser.

Hvordan ser Front End Development ud nu?

Nu er det almindeligt at se javascript-tunge websteder og apps bygget ved hjælp af UI-rammer som React, Vue og Angular. Disse værktøjer giver abstraktioner, der giver udviklere mulighed for at opbygge komplekse brugergrænseflader med genanvendelige mønstre som komponenter.

Når browseren indlæser siden, modtager siden et indledende HTML-dokument, der også inkluderer script-tag til javascriptet (det samme som altid). Men når dette javascript er indlæst, når det ud til API'er ved hjælp af browseranmodninger, når opdateringen opdateres, så den udfylder enhver form for dynamiske data, som du typisk kommer sammen med det første HTML-dokument.

Selvom det lyder som flere trin, giver det normalt en hurtigere indledende sideindlæsning og gengivelse, for ikke at nævne, at den har en god udvikleroplevelse. Ved at levere mindre på den første anmodning og prioritere, hvad der indlæses efter det, ender det normalt som en bedre brugeroplevelse.

Nogle af frontendeværktøjerne, der er mere almindelige og vokser i popularitet, inkluderer:

  • UI-rammer som React eller Vue
  • Webrammer som Gatsby
  • Kompilatorer som Babel
  • Bundlere kan lide Webpack
  • CSS-værktøjer som Sass

Men disse API'er, hvad enten vi betaler for eller opretter os selv, skal bygges et eller andet sted . Det er her bagenden kommer ind.

Hvad er Back End Development?

Bagsiden er normalt, hvor forretningslogikken opstår. Dette kan være superkompleks som de regler, der bestemmer indtægterne for en e-handelsvirksomhed eller noget mere almindeligt som en brugerprofil.

Hvordan så Back End Development traditionelt ud?

Bagenden af ​​applikationer blev historisk bygget ved hjælp af serversprog som PHP eller Ruby. Ideen er, at du har en server, som du skal udføre komplekse operationer på, så måden at gøre det er på et sprog, som serveren ville forstå.

På hver anmodning til serveren udførte backend den fulde stak af operationerne, inklusive gengivelse af frontend. Ved at bruge rammer eller DIY-arkitekturer, accepterer bagenden anmodningen, finder ud af, hvad den skal gøre med denne anmodning, kører enhver forretningslogik, der er nødvendig med anmodningen, og giver frontend alle data, som den har brug for for at vise et svar den anmodning.

Nogle af de mere traditionelle backend-værktøjer inkluderer:

  • Lokale eller fjernadministrerede servere som Rackspace
  • HTTP-servere, der bruger Apache
  • Databaser som MySQL
  • Server-sidesprog som PHP eller Perl
  • Applikationsrammer som Ruby on Rails

Hvordan ser Back End Development ud nu?

Backend-stakke ser noget ud som de gjorde før, bortset fra nyere kodemønstre, undtagen oftere vil du se, at bagenderne leverer data gennem API'er via HTTP-anmodninger i stedet for direkte til de skabeloner, som frontend-teamet arbejder på.

Mens fundamentet ikke er super anderledes, kommer det faktisk stadig mere komplekst, da du skal håndtere forskellige sikkerhedsimplikationer, der kan kompromittere dit system, hvis det ikke er korrekt konfigureret, såsom at lade en API være åben for offentligheden, der returnerer følsomme brugerdata.

Men også hvordan serveren fungerer, kan være helt anderledes. Mens vi tidligere kørte vores python på vores egen administrerede server (vi stadig kan), kan vi nu bruge serverløse funktioner med værktøjer som AWS Lambda, der forenkler, hvordan vi administrerer kode.

Mens "serverløs" ikke nødvendigvis betyder, at der bogstaveligt talt ikke er nogen servere, betyder det, at udvikleren som en tjeneste ikke behøver at bekymre sig om at vedligeholde den server og i stedet bare kan fokusere på den kode, de har brug for at køre.

Nogle af de bageste værktøjer, der er mere almindelige og vokser i popularitet, inkluderer:

  • Cloud-servere som AWS EC2
  • Serverløse tjenester som AWS Lambda
  • NoSQL-databaser som MongoDB
  • Sprog som Python eller javascript via NodeJS
  • Webapplikationsrammer som Serverless Framework

Hvor ting bliver fuzzy

En del af vridningen med bagenden er, at du nu kan skrive din bagende med javascript. Med starten på Node.js fik udviklere mulighed for at bruge deres yndlingsbrowsersprog til at gøre de fleste af de samme ting, som de var vant til og fortrolige med, men nu på en server.

Selvom ikke alle er glade for at køre javascript som serversprog, blev det lidt lettere at bruge det samme sprog til at skrive den fulde stak af et program. Dette ændrede spillet en smule for så vidt angår frontend og backend.

Men det er også begyndt at komme i fuld cirkel, hvor du nu ser systemer, der bygger API'er lige ved siden af ​​frontenden svarende til hvad du kan se i en traditionel stak.

Front End vs Back End

Uanset stakken vil der altid være adskillelse af bekymringer. UI og al interaktion, uanset om det gengives på serveren eller i browseren, er det, der gør frontend til frontend og data- og forretningslogik, hvad enten det kommer fra serveren i din virksomheds skab eller en administreret funktion, er det gør bagenden til bagenden.

Uanset om du foretrækker at arbejde på de brugervendte funktioner eller opbygge logikken, der lader dem gøre ting, er der masser af ressourcer til at komme i gang.

Ressourcer at lære

Frontend

  • freecodecamp.org Responsive Web Design-certificering (freecodecamp.org)
  • Begynder-Javascript (beginnerjavascript.com - Wes Bos)
  • React-tutorial til begyndere (youtube.com - Programmering med Mosh)
  • Front End Masters (frontendmasters.com)

Bagende

  • freecodecamp.org API'er og mikroservicecertificering (freecodecamp.org)
  • Super simpel start på serverløs (kentcdodds.com)
  • AWS Certified Cloud Practitioner Training 2019 - Et gratis 4-timers videokursus (freecodecamp.org)
  • CS50's introduktion til datalogi (edx.org)

Alt ovenstående

  • Sådan bliver du en Full Stack-webudvikler i 2020 (colbyfayock.com)
  • Egghead.io (egghead.io)
  • 100 dage med kode (100 dage fra kode.com)
  • Webudvikler Bootcamp (udemy.com - Colt Steele)

Følg mig for mere Javascript, UX og andre interessante ting!

  • ? Følg mig på Twitter
  • ? ️ Abonner på min Youtube
  • ✉️ Tilmeld dig mit nyhedsbrev