En sammenligning mellem Vulcan og AUSK: hvordan man bruger Node, React og GraphQL til deres fulde potentiale

NRG-stakken til hurtigere udvikling

Du har sandsynligvis aldrig hørt om hverken Vulcan.js eller Apollo Universal Starter Kit - i det mindste ikke endnu.

Men jeg er ret sikker på, at du har hørt om React, Node.js og GraphQL. Okay, det er det, vi kalder en underdrivelse: Du har sandsynligvis set millioner af tweets, blogartikler, meetups og podcasts om disse tre og deres magiske kræfter.

Der er mange gode grunde til, at disse teknologier roses af webudviklere. Alligevel, hvis du nogensinde har forsøgt at skrive en moderne JavaScript-applikation med fuld stak fra bunden, har du måske bemærket mængden af ​​kedelplade, den kan producere.

Dette er især irriterende med generiske funktioner: opsætning af godkendelse, opsætning af databasen, opsætning af den vigtigste app-komponent, opsætning af indstillinger ...

Både Vulcan.js og AUSK sigter mod at gøre dig til en hurtig og effektiv JavaScript-udvikler med fuld stak. Begge er afhængige af en modulær arkitektur med React for UI, Node for backend og Apollo graphQL til client / server-kommunikationslaget. Begge giver masser af forkodede moduler, så du kan fokusere på værdifulde funktioner.

Men de tager hver især meget forskellige tilgange til problemet, så jeg tænkte, at du måske kunne lide en sammenligning.

Lad os først introducere konkurrenterne.

Ansvarsfraskrivelse: Jeg er en bidragyder af Vulcan.js, men jeg brugte begge disse teknologier til min klients projekter, så jeg forbliver så objektiv som muligt.

Apollo UNIVERSAL Starter Kit

Okay, når de siger universal, betyder de UNIVERSAL. Har du nogensinde set en JavaScript-kedelplade, der inkluderer en Scala-server til stort arbejde? Og en komplet React Native-opsætning med Expo? De lukker endda den evige (og irriterende) Angular versus React-debat ved at støtte begge.

Jeg har ikke meget andet at sige. Jeg mener, se igen på denne stak, det er en webudviklers vildeste drøm!

Jeg har faktisk noget at tilføje: det inkluderer også Bootstrap og Ant Design som styling-rammer, Knex for at oprette forbindelse til SQL-database (MongoDB-forbindelse er ikke inkluderet men let gennemførlig), og den er skrevet i TypeScript. Alle kerneegenskaber i en JS / GraphQL-applikation findes i kedelpladen (menu, godkendelse osv.) + Et par moduler på højere niveau, der fungerer som eksempler.

Link: //github.com/sysgears/apollo-universal-starter-kit

Vulcan: ud over universel, isomorf

Husker du meteor og teleskop? Jeg ved, at JS-økosystemet bevæger sig hurtigt, men denne gyldne æra var som kun for 2 eller 3 år siden.

Meteor var den første ramme til fuldt ud at udnytte kombinationen af ​​JavaScript og server-side ved at tillade at skrive isomorf kode, der kører på begge miljøer. Telescope var en Meteor boilerplate-app beregnet til fuldt ud at nyde sin pakkeorienterede arkitektur.

Selvom det stadig bruges i mange professionelle apps og kendt af en hel masse udviklere, er Meteor lammet af nogle tekniske begrænsninger, der forhindrer en bredere anvendelse: dets webpack-inkompatible build-system, dets pakkehåndtering, der nu er overgået af NPM, eller dets RAM- forbruge protokol i realtid til dataudveksling.

Og jeg skal endnu ikke finde en ramme, der gør devs halvt så produktiv som Meteor. Men rolig, der er nu en seriøs udfordrer. Du får det: Vulcan!

Brug af Apollo GraphQL og en rationel pakkeorienteret arkitektur gør det muligt for Vulcan at overvinde Meteors begrænsninger, mens de nyder de samme fordele: fuldt modulær arkitektur, deklarativ programmering, isomorfisme og så videre.

Vulcan er beregnet til at være skinnerne i JavaScript-økosystemet. Let at komme i gang med, men fuldstændig nok til at skrive enhver app.

Se min tidligere artikel for en mere komplet beskrivelse af Vulcan-mønstre, der er målrettet mod udviklingshastighed.

Link: //vulcanjs.org/

# 1: Framework VS Boilerplate

Første store forskel mellem disse værktøjer: AUSK er en kedelplade, mens Vulcan er en ramme. Hvor ligger forskellen, undrer du dig måske?

Vulcan, en ramme

En ramme er beregnet til at gøre dig til en mere effektiv udvikler på daglig basis ved at levere et specifikt sæt funktioner og hjælpere. Det er normalt designet til at holde sig adskilt fra din app. Du kan opdatere din app fra tid til anden, hver gang en ny version af rammen offentliggøres.

Vi skelner normalt rammer og biblioteker baseret på specialiseringsniveauet. En ramme giver normalt mulighed for at levere funktioner på forretningsniveau, mens et bibliotek er et mere specialiseret teknisk værktøj. Men begge fungerer for det meste det samme.

Begrænsningen med rammer eller libs er, at du kan føle dig tabt, når de opgiver dig. Hvad laver du, når fejlen ikke findes i din app, men i React eller Apollo?

Min tommelfingerregel er, at når du bruger en ramme, skal du være klar til at bidrage til dens udvikling, i det mindste ved at åbne problemer, når du støder på en fejl.

AUSK, en kogeplade

En kedelplade er et velskrevet stykke kode med et fuldt fungerende udviklingsmiljø. Det er alt. Med en kedelplade er det sværere at holde trit med opdateringer, fordi kedelpladekoden ikke er klart adskilt fra din app. En slags som Opret React-app, når du skubber ud.

Det giver normalt kun få brugerdefinerede metoder. Du vil føle dig hurtigere i den første måned, og du vil drage fordel af en kamptestet arkitektur, men din krydstogtshastighed ender med at være mest den samme end uden en kedelplade.

En kedelplade er langt mere frihed end en ramme, men også mindre indflydelse på din effektivitet.

# 2 Læringskurve

Vulcan: GraphQL gjort let

Vulcan kan være en god måde at få et første greb om GraphQL, fordi ... du ikke behøver at skrive GraphQL. Rammen genererer GraphQL-skemaet og resolverne for dig baseret på din datamodel. Ved hjælp af udviklerværktøjer som GraphiQL eller GraphQL Voyager kan du visualisere og lege med skemaet for at få en forståelse af, hvordan dine funktioner oversættes til GraphQL.

Det andet trin er at forstå logikken i Vulcan selv. En live tutorial er inkluderet i "Vulcan Starter" -appen for at hjælpe dig i processen.

AUSK: for purister

AUSK-arkitekturen er langt tættere på, hvad Express-udviklere er vant til. Tænk på din kanoniske Express-app, men med GraphQL installeret og en pakkebaseret arkitektur. Ingen overraskelser.

Dette betyder også, at du bliver nødt til at forstå det grundlæggende i GraphQL for at bruge AUSK, udover selvfølgelig til Node, Express og React og hvilken database du bruger (men det samme gælder for Vulcan). Heldigvis giver det et par eksempler, der kan hjælpe dig i processen, herunder oprettelse og notering af data og endda upload af filer.

Konklusion: Full-stack devs har meget at mestre

JavaScript-økosystemet modnes mere og mere, hvilket også betyder, at det er sværere at lære og forstå for begyndere.

For fuldt ud at nyde disse teknologier skal du i det mindste have noget kendskab til moderne JavaScript og React-udvikling.

Forvent ikke at være fuldt produktiv på første dag. Når det er sagt, er der masser af kurser, gratis eller betalt, for at lære moderne fuld-stack JavaScript-udvikling. At studere AUSK og Vulcan kan være en utrolig inspirationskilde.

# 3 Udviklingshastighed

Vulcan: automatiser alle tingene

Når det er godt brugt, er Vulcan bare utrolig hurtig til at levere funktioner. Dette skyldes, at det er meget afhængig af automatiseret generation, så det kan producere de mest relevante dele af en app i løbet af få timer, så længe din datamodel er korrekt defineret.

Dette mønster kaldes deklarativ programmering: du “erklærer”, hvordan din app fungerer, og lader rammen gøre jobbet. Det er vanskeligt at implementere, men kan være ekstremt stærkt.

AUSK: mere frihed

Da AUSK er kedelpladefokuseret, er det lidt sværere at tilføje grundlæggende funktioner, da det er en proces i flere trin:

  • skriv dit GraphQL-skema
  • det samme for resolvere, mutationer
  • det samme for din databasemodel (ved hjælp af Knex eller Mongoose)
  • det samme for dine React-komponenter
  • ...

Imidlertid,Hvis du har brug for at skrive en brugerdefineret funktion, bliver det lettere med AUSK end med Vulcan. Så hvis du har meget få datamodeller men komplekse funktioner, vil AUSK være mere effektiv end Vulcan.

Forhåbentlig arbejdes der løbende med at gøre AUSK mere deklarativ gennem et innovativt Domain Driven Design inspireret skema system, domæneskema.

Konklusion: vælg det rigtige værktøj til den rigtige brugssag

Der er ingen magisk universel teknologi til fuld stack-JS-udvikling. Udviklingshastigheden for hver ramme afhænger meget af den underliggende brugssag. Jeg har en tendens til at foretrække Vulcan til dataorienterede platforme og professionelle værktøjer og AUSK til B2C SaaS-platforme, der kræver flere brugerdefinerede funktioner.

# 4 Fællesskab, støtte og modenhed

Vulcan: arving af Meteor

Vulcan er en ramme fra Sacha Greif, som i lang tid er meteorudvikler og meget investeret i JavaScript-samfundet (State of JS og State of CSS blandt andet).

Der er en aktiv Slack, hvor begyndere og andre entusiaster hurtigt kan finde svar på deres spørgsmål.

AUSK: et aktivt vedligeholdt projekt

AUSK vedligeholdes af SysGears, især af Victor Vlasenko, grundlæggeren af ​​virksomheden.

Projektet er tilknyttet Gitter. Under min seneste freelance-mission med AUSK reagerede Victor meget hurtigt på mine problemer og spørgsmål. Han flettede endda Storybook-understøttelsen, efter at jeg gav det et skud.

Konklusion: små, men rige samfund

Begge teknologier bruges i produktion i flere projekter, så de er allerede sikre at bruge. Samfundene vokser aktivt og begyndervenligt.

Hvis du har brug for at opbygge et team, skal du ikke forvente at finde freelancere, der præcist kender disse teknologier, de er for specifikke. Fokuser i stedet på at finde JavaScript-udviklere med fuld stak, som hurtigt kan lære dem. Alternativt kan du gå til kilden og finde ægte specialister blandt Vulcan- eller AUSK-samfundene.

# 5 Implementering

Ikke meget at sammenligne, begge rammer tillader implementering på platforme, der tilbyder gratis tjenester som Zeit Now og Heroku samt implementering på din egen brugerdefinerede server.

# 6 Kode skalerbarhed og modulære mønstre

Vulcan: del indsats

En fordel ved en ramme er deling af indsats. Slutbrug er klarere og giver os således mulighed for at integrere forskellige optimeringer inden for selve rammen.

Vulcan leverer mønstre som callbacks / hooks, forbedring og central registrering for fuldt ud at drage fordel af sin pakkeorienterede arkitektur. For eksempel er vi i stand til at tilføje Material UI til en app, inklusive SSR, uden at ændre en enkelt kodelinje i Vulcan Core-modulet.

Mere præcist giver Vulcan forskellige registermetoder til hver datastruktur, ligesom registerComponentog også tilbagekald, som router.wrapperdet gør det muligt at indpakke root AppReact-komponenten. Du behøver kun at importere din fil en gang på pakkeindgangsniveauet ( mainfiler).

AUSK: start på det rette spor, slut af dig selv

Den modulære arkitektur begrænser fristelsen ved at skrive spaghetti-kode. Det favoriserer genbrug af kode på tværs af applikationer. Hver pakke har en index.tsfil, der erklærer relevante mellemværker, startfunktioner, grafQL-funktioner, der deles med andre moduler.

Det velkendte modulemodul giver klasser for hvert miljø til at registrere et nyt modul, ligesom ServerModuleog ClientModule. Det er det eneste modul, der faktisk bruges direkte på app-niveau.

 export default new ServerModule({ onAppCreate: [ callback1, callback2] }) 

Internt bliver alle moduler flettet til et stort modul, der til sidst vil blive brugt til at oprette appen. For eksempel onAppCreatekøres alle tilbagekald efter hinanden.

Det er et relativt rent mønster og en meget smart arkitektur. Jeg mener, selv moduladministratoren er et modul, er det ikke smukt?

Men resten er op til dig. Dejligt, du kan optimere alt! Så vil du miste parring af dine GraphQL-opløsere og din Mongo-database? Brug af hvilke værktøjer? Hvordan konverterer du dit GraphQL-skema til Mongo-fremskrivninger? Skal du skrive stik, bruge DataLoader?

Her er pointen: at skrive en skalerbar app er svært. Meget hård. Hvis du vil lære, så godt for dig. Jeg er meget glad for at bruge AUSK af netop denne grund. At gøre ting selv er den bedste måde at lære på.

Konklusion: er du risikovillig?

For både AUSK og Vulcan betyder kode skalerbarhed en modulær arkitektur. Når kode bliver for kompleks eller ulæselig, er løsningen let: skær den i mindre, enklere stykker.

Vulcan-arkitekturen er dristigere, alt kan være modulært. Denne ambition risikerer, det kan nogle gange være svært at få hvem der har registreret hvad og hvornår.

AUSK modulære mønstre er lettere at læse, men også lidt mindre kraftfulde. Det kan f.eks. Være vanskeligt at tilføje komplekse globale funktioner uden at røre ved kernepakkekoden. Alligevel er de bestemt tilstrækkelige til de fleste brugssager, du behøver ikke være en modularitetspurist for at skrive gode apps.

# 6 Mobil

Vulcan: med Cordova

Meteor, som Vulcan er baseret på, indlejrer Cordova. Så din webapp kan samles som en mobilapplikation med en enkelt kommandolinje.

Vulcan leverer dog ikke værktøjer til native apps. Selvfølgelig kan du stadig oprette en uafhængig React Native-app og tilslutte den til Vulcan. Forbedringer af godkendelsessystemet (i øjeblikket det sidste stykke Vulcan, der virkelig stoler på Meteor) er planlagt i de kommende måneder for at lette sådanne forbindelser.

AUSK: med React Native

At kombinere både en opsætning til “vanille” React og React Native er en af ​​de bedste funktioner i AUSK. Når alt kommer til alt er det et Universal starter kit! Jeg laver ikke meget mobil selv, men det er betryggende at være i stand til hurtigt at oprette en indbygget mobilapp, der deler den samme server som min webgrænseflade.

Konklusion: AUSK er bedre til mobil-først

AUSK vil være mere egnet, hvis du specifikt har brug for at skrive en mobilapp. Ikke desto mindre tillader Vulcan at oprette en mobilapp fra din kode på kun en kommandolinje, hvilket er okay, hvis mobilversionen er mere sekundær for dig.

# 7 Skift brugergrænseflade: et hårdt problem

Oprettelse af en fullstack-ramme, der tillader øjeblikkelig ændring af UI-biblioteket, er en drøm, der kun opnås i løbet af CSS-æraen. Husk de websteder, der tillod at skifte tema ved at klikke på en enkelt knap?

Derefter angreb JS-nationer. Ved hjælp af React-komponenter er det meget vanskeligt at give en sådan funktion (bortset fra trivielle farveændringer), fordi stil og design nu er meget bundet til de underliggende React / Angular / Vue-komponenter.

Hver React UI lib har sin egen måde at definere en knap på uden at tale om temaer. Det er et problem for full-stack teknologier som AUSK og Vulcan, fordi det at vælge en styling-ramme er et spørgsmål om smag. De kan ikke bare foreslå et endeligt valg og tvinge dig til at holde fast ved det. Bootstrap har ikke længere monopol, og hver udvikler har deres egen yndlings-lib.

For at tackle dette problem har begge en lignende tilgang. De skrev et kanonisk sæt komponenter med Bootstrap og forsøgte derefter at udskifte disse komponenter med en anden lib som Ant Design eller Material UI.

Det gør koden underlig. For eksempel vil AUSK Button tage en colorprop, fordi det er sådan, Bootstrap fungerer. Hvis du skifter til Ant Design, skal du også bruge farvepropen, selvom Ant Design bruger en typeprop i stedet for.

Da UI-rammevalg normalt kun sker en gang, synes det at være en meget høj pris for multipel UI-rammesupport at være forpligtet til at bruge et ikke-kanonisk sæt rekvisitter under hele udviklingen.

Under udviklingen vil jeg foreslå at undgå at bruge disse forkodede komponenter til brugerdefineret brugergrænseflade så meget som muligt. De er seje til at oprette eksemplet og de generiske funktioner leveret af kedelpladen / rammen, men ikke så meget, når det kommer til at skrive de brugerdefinerede dele af din app.

Brug i stedet de underliggende komponenter leveret af Ant Design eller Bootstrap eller Material UI afhængigt af dit valg, og prøv at skrive dit eget UI lib. Du kan tjekke Storybook for at hjælpe dig i processen, da den er inkluderet i både AUSK og Vulcan.

# 8 GRATIS KAMP

Hvis jeg skulle bevare forskellige funktioner, der er specifikke for hver af disse teknologier, ville de være disse.

Vulcan

Skema-systemet. Efter min bedste viden er ingen rammer i stand til at generere databasestrukturen, serverindgangspunkterne, klient / serverkommunikationslaget og en produktionsklar frontend (formularer, lister osv.) Fra et enkelt JSON-skema.

Vulcan.js kan gøre det, mens de bruger de nyeste JS-teknologier.

AUSK

Det lykkedes mig ikke kun at vælge en, så mine elskede funktioner i AUSK ville være TypeScript og React Native.

Der har været debatter i et par år omkring fordelene ved statisk skrevet JavaScript, om de foretrækker Flow eller TypeScript ... Og TypeScript vandt bestemt kampen. Arbejde med TypeScript er muligt i Vulcan, men på grund af brugen af ​​Meteor føles det i øjeblikket unaturligt, og kompilering er langsom. AUSK bruger TypeScript som standard, og det er fantastisk.

Og React Native ... godt, der er ogsådebatterer, om det er relevant at bruge React til at skrive mobilapps. Du kan vælge at holde dig til en lydhør webapp, men i det mindste ved du, at alt er konfigureret til dig, da det ikke altid er en let opgave at konfigurere en dev env til React Native.

Så har du truffet dit valg?

Der er så mange punkter, der skal tages i betragtning som ydeevne, sikkerhed, DevOps, auth management ... At vælge det rigtige værktøj til at oprette din JavaScript-app er bestemt ikke et let valg. Jeg håber, at denne artikel gav dig værdifuld indsigt til at hjælpe dig med denne beslutning.

Hvis du stadig er tøvende, nå mig ud på Vulcan's Slack, jeg ville være glad for at svare dem :)

Du kan også rette ethvert spørgsmål om AUSK til Victor Vlasenko og hans team hos SysGears og tilslutte dig Vulcans dedikerede Slack for at få adgang til Vulcan-samfundet.

Mit sidste råd vil være så simpelt: Giv både Vulcan og AUSK et skud, de er din tid værd!

Tak til Sacha Greif og Victor Vlasenko for at have gennemgået denne artikel.

LBKE banner twitter

Jeg er medstifter af det franske firma Lebrun Burel Knowledge Engineering (LBKE) - //www.lbke.fr

Altid glad for at tale om kode, maskinlæring, innovation og iværksætteri!