node.js - NestJS VS AdonisJS
Jag är på väg att påbörja ett nytt projekt. Hittills har jag arbetat med ExpressJS för min backend, men jag märker att jag uppfinner hjulet lite för mycket. Eftersom jag alltid strävar efter att förbättra mina projekt, hittar jag mig själv spendera mycket tid på teknologival och projektstruktur för att säkerställa att det är rent och skalbart. Därför planerar jag att byta till Nest JS eller Adonis JS, eftersom de är ganska förutsägbara ramverk som kräver en viss struktur och specifika verktyg i sin kärna.
Min benägenhet lutar mer åt Adonis JS än Nest, och jag skulle vilja veta om det finns några medlemmar som har erfarenhet inom detta område eller som kan ge mig annan information eller kommentarer som kan påverka mitt val av teknik? (med vetskap om att backend för det nya projektet jag kommer att arbeta med kommer att vara komplex)
Tack.
Svar #1
Jag känner personligen inte till Adonis JS, men jag har använt Nest JS och det verkar ganska bra som backend-ramverk.
Ärligt talat gillar jag inte åsiktsfulla ramverk eftersom jag föredrar att ha full kontroll över arkitekturen och valet av bibliotek
I det följande markerar jag några punkter att tänka på mellan ramverk med åsikter och ramverk utan åsikter
Fördelar
- Batterier inkluderade: Vanligtvis kommer opinionerade ramverk med batterier inkluderade, vilket tillhandahåller alla nödvändiga verktyg för att uppnå en bra mjukvaruarkitektur och produktstabilitet
- Automatisk arkitektur: Ditt fokus som utvecklare kommer endast att bestå i att implementera funktionalitet och förlita dig på ramverkets struktur
- Påskynda projektuppsättningen
- Snabb teamintroduktion: I framtiden, om du planerar att introducera nya utvecklare i projektet kan du leta efter personer som redan känner till det specifika ramverket och de kommer bekvämt kunna arbeta på ett okänt projekt eftersom det följer standarder som är ganska identiska över projekt.
- Underhållbarhet: Populära ramverk har stora bidrag och är i ständig utveckling, även om detta kan vara ett problem om du föredrar att hålla dig till en specifik filosofi
Nackdelar
- Gränser: Det är verkligen svårt att korsa gränserna, om du behöver ett särskilt beteende som inte är en del av ramverkets filosofi är du körd, och glöm att posta ett problem på ramverkets GitHub, det vanligaste svaret kommer att vara:
Det är ett designval att hålla det enkelt
And commonly this is also correct, but you still remain with your issueStort projekt: Ramverk med fulla funktioner inkluderade är verkligen tunga, eftersom de tillhandahåller många inbyggda bibliotek som inte alltid är användbara för alla projekt, så frågan bör vara:
Behöver jag allt detta?ochKan jag hantera all denna komplexitet?Svår låg-nivå felsökning: Eftersom du konstant lever i
svarta lådankan du ha någon form av svartmagiskt problem och det kommer att vara mycket svårt att genomföra en hjälpsam undersökning, generellt kommer kreativa och konstiga lösningar in, ibland kan du till och med behöva möta en återställning av ramverksversionen medan du väntar på en slutlig lösningVendor Lock: Även om vi talar om ett open source-ramverk är du bunden, och om ramverket en dag ändrar filosofi eller ännu värre om det arkiveras, är du fast
Hur man väljer rätt ramverk?
Enligt min uppfattning tycker jag att du måste överväga bara några få punkter och fatta ett beslut baserat på dem
- Har ramverket jag valde allt jag behöver?
- Har det ramverk jag valde mer av det jag behöver än ett annat ramverk?
- Hur många stjärnor har ramverket? Jag förstår att den här frågan kan vara kontroversiell, det finns många mindre populära ramverk som gör ett enormt bättre jobb än andra, men i ett åsiktsbaserat sammanhang bör du ta hänsyn till gemenskapen, som representerar basen för många framtida problemlösningar, så:
mindre populär=mindre gemenskap=mindre hjälp
Några mindre punkter, men fortfarande relevanta:
- Inlärningskurva, du bör vara bekväm med inlärningsprocessen
- Gränser barriär, på samma nivå, den som får dig att gå bortom gränserna mest, är bättre
Jag hoppas att jag har gett dig några tips för att hjälpa dig att fatta det klokaste beslutet.
Ramar och bibliotek om du överväger att gå en icke-åsiktssättande väg
- [TSOA - Som controller manager, swagger och mycket mer][1]
- InversifyJS - Omvänd kontroll och beroendeinjektion
- Swagger UI för att visuellt presentera auto-genererad swagger [1]: https://github.com/lukeautry/tsoa