The Saruni application structure has been designed to support applications large and small and is a requirement to take advantage of
saruni commands in your workflow.
.├── package.json├── packages│ ├── admin│ ├── api│ │ ├── prisma│ │ ├── src│ │ │ ├── db│ │ │ ├── functions│ │ │ └── graphql│ │ │ ├── resolvers│ │ │ └── typeDefs│ │ └── tests│ ├── shared│ ├── static│ │ └── emails│ └── web│ ├── generated│ ├── src│ │ ├── components│ │ ├── graphql│ │ ├── hooks│ │ ├── layouts│ │ ├── pages│ │ └── views│ └── tests└── saruni.json
Saruni utilizes the Workspaces feature of
yarn to make dependency management simpler. That means any workspace outlined in the
workspace field of the root
web, etc.) will have its dependencies hoisted to the root level on install.
api directory is home to the business logic of our application. It includes the
prisma directory where representations of database tables will be created through models. The directory is also home to a
functions directory where we can define any number of serverless functions to handle tasks like authentication and image uploads. We also find the
graphql directory here, where we write query markup to interact with our database.
web directory contains the interface layer for our application. Routes are created through exports in the
pages directory and will often share layouts, which can be defined in the directory of the same name. We create encapsulated UI elements in the
components directory and export repeated uses of those elements from the
views directory. For example, we could create a generic
Dropdown element and export a multi-use
UserDropdown implementation of that element to avoid polluting the
graphql subdirectory is where we define GraphQL queries and mutations in
.graphql files, from which we can auto-generate hooks through Saruni CLI. These hooks are output to the
generated subdirectory, whilst all other reusable stateful logic we write ourselves can be added to the dedicated
shared directory may be used to store logic that is helpful to both our business logic and interface layers. For example, validation logic for user creation could be written with a
yup schema and used in both a client form and the mutation that form calls to avoid a mismatch across our stack.
static directory is where you may define content that will be often compiled down to plain text or simple HTML markup. Email content, legalese and support documents are good examples. This content might be changed frequently by those without engineering experience, so abstracting the contents away from application logic is often helpful.