Sådan organiseres ekspress-controllere til store kodebaser

For tre år siden begyndte jeg at udvikle en Express.js API til en virksomhed. Jeg spekulerede på, hvad der kunne være den bedste controller-arkitektur til at forblive organiseret, når kodebasen vokser.

Påvirket af sejl eller skinner og af min forskning kom jeg til at oprette mit eget system. Jeg ville ikke overbelaste mit projekt ved hjælp af en komplet ramme som Sails, men vælg lettere afhængigheder, når det var nødvendigt.

Så jeg oprettede et organisationssystem til appens controllere, som jeg parrede med en hjemmelavet læsser . Siden da har jeg forbedret dem begge takket være den erfaring, jeg har fået ved at implementere den på andre projekter.

I dag er jeg sikker nok på denne metode til at dele den, da resultaterne er overbevisende.

Fra hvad jeg ved, bruges det af et par store virksomheder. Det forenkler ombordstigning af nye udviklere, da det gør codebase lettere at læse.

✅ Sådan oprettes en ren controllearkitektur.

Strukturen

Hvis du ikke forventer væksten i din app, får du hurtigt en uorganiseret codebase. Jeg designet organisationsmetoden til at have bred kompatibilitet, hvilket betyder, at du en dag ikke bliver låst fast i en slags brugssag, du ikke kan løse med denne metode.

Opsæt dit filtræ

  • Gruppér ruter i controllere
  • Opret mapper til hver controller
  • Opret en routing-fil i hver controller, der beskriver stien til hver rute, metoden til opkald, dens eventuelt tilknyttede middleware og begrænsningsniveauet.
  • Opret en fil til hver controllers handlinger, der indeholder metoden til udførelse og mellemwares .
  • Opret en spec-fil til test

Lad os se, hvordan det ser ud.

Vær ikke bange for at oprette mange filer . Det bremser ikke udviklingen, og det gør din codebase pæn og luftig. ✨

Indlæs dine ruter

For at få tingene til at fungere efter den ovenfor definerede struktur, skal vi bruge en simpel læsser, jeg oprettede: Lumie. Det vil gå gennem dine controllere, læse definitionsfilerne og indlæse dine ruter.

Det er en lille pakke, du kan tjekke for at kode kilde på GitHub.

Routing af filer

De er designet til at være nemme at læse. Formålet er at være i stand til at identificere metoder til opdatering i udvikling ved at kigge hurtigt i dine .routing- filer. I det følgende eksempel oprettes tre ruter:

  • [PUT] / bruger
  • [GET] / bruger
  • [GET] / bruger / reset-adgangskode

Du undrer dig over, hvorfor ruter er forud for " bruger ", selvom det ikke er beskrevet i rutedefinitionen. Lumie bruger navnet på den mappe, hvor routingsfilen skal foregå ruter.

Her er vi inde controllers/user/user.routing.js. Hvis usermappen f.eks. Har været i en undermappe admin, ville ruterne være forud for admin/user.

Bemærk, at du kan videregive et valgfrit pathfelt til rutedefinitionen, så det bruges i stedet for standardfeltet.

Handlinger og mellemprodukter

Som du kan se ovenfor, har hver rutekonfiguration en handlingsmetode, der kun er logikken, der skal udføres, når vi kalder din API-rute. Jeg anbefaler, at du holder i en fil: en handlingsmetode og dens valgfri tilknyttede middleware .

Begrænsninger

For hver rutekonfiguration skal du vælge det tilknyttede begrænsningsniveau. Niveauværdien overføres til den begrænsningsfunktion, du opretter for at få Lumie til at fungere. Se, hvordan du initialiserer Lumie med din egen begrænsningsfunktion.

Dette skal bare være en funktion, der returnerer en klassisk ekspress middleware.

Konklusion

Jeg har brugt denne metode i et stykke tid nu. Jeg kan godt lide at have denne slags meningsfulde rammer at følge, når jeg udvikler mig. I slutningen af ​​dagen hjælper det mig med at holde en god codebase og ikke tage genveje som at skrive for meget logik i en fil eller definere en rute i en upassende fil.

Tak for læsningen. Fortæl mig i kommentarerne, hvad du synes om at organisere controllere på denne måde.

Hvis du fandt denne artikel hjælpsom, så slip nogle? ?