Architecture and Folder Structure
Learn how MakerKit allows you to build a Next.js application with a scalable and production-grade architecture and folder structure
MakerKit's primary goals are:
- Solid Foundations - providing you with the necessary code to get up and running with a Saas with minimal configuration
- Extendable and Adaptable - the ability change and extend the codebase as efficiently as possible
While it's relatively simple to provide a functioning codebase, it's not always easy to make it:
- Simple - a clean codebase quickly understandable by anyone
- Easy to change - a codebase that can be easily changed to a particular domain
Once you get started on your project, you can begin unpicking and replacing the existing code to adapt it to your application's domain. At the same time, MakerKit may have pushed an update that fixed a bug or added a new cool feature.
The two projects will diverge, and quite inevitably, end up in a conflicting state.
Thankfully, Git makes it easy to merge conflicts. But it's still a hassle.
To reduce the number of possible conflicts, MakerKit ships with a particular folder structure:
- src - lib - components - pages - api - core
These folders represent four separate layers. MakerKit is an Onion:
Let's talk about the lower level: the
core. This layer is a collection of building blocks, utilities, and API that make up MakerKit.
This part of the boilerplate is configurable and makes no assumptions about your domain.
You are still welcome to change this code to suit your needs, but you can expect most updates from upstream to change code in this directory.
The mid-level is in two separate folders (to avoid excessive nesting):
lib: here is where we write most domain-related business logic (hooks, contexts, queries, mutations, etc.)
components: here is where we write the domain-related components (ex. Profile Page, Create Project form, etc.)
MakerKit comes with some business logic (it would be nearly impossible otherwise to build a genuinely functioning SaaS). You should customize the existing logic for your application, and it is likely where you will add most of your code.
This layer can still be updated by upstream, but you should not expect too many changes unless it's additions for new features or bug fixes.
pages layer is the outer layer of the application.
It's entirely dependent on your application, and you should not expect updates from upstream unless for fixing blatantly buggy code.
eslint to check that imports are flowing correctly through your application: if this feds you up, you can remove them from the
eslint configuration at