GELLIFY.dev

Get started

Architecture

In this stack we tried to follow all of the best practices of the different components that are used to enable the various features. In order to offer some default we pre-configured the following layers:

  • ✅ App Layer, a standard Next.js app
  • ✅ Auth Layer, a Clerk instance
  • ✅ Data Layer, a Postgres instance managed by Neon with Drizzle
  • 😌 That's it!

Below you can find a diagram representing an high level overview of architecture we strived to implement. This fullstack template aims to reduce complexity, increase DX and reduce dependencies overhead.


Application Architecture

Next.js application deployed on Vercel with Clerk authentication and Neon database

Architecture - App Layer

The application is build following all of the latest Next.js 15 best practices and guidelines. Please refer to Next.js official docs↗ to get a better understanding of the available features. The standard Next.js application layer features:

  • Middleware↗ -> middleware.ts single point of ingress into the app
  • API Routes↗ -> /app/api/**/route.ts REST APIs
  • Server Actions↗ -> /app/actions.ts new way to handle data querying and mutation
  • RSC↗ (React Server Component) -> /app/**/*.tsx default or annotated with use server
  • RCC↗ (React Client Component) -> /app/**/*.tsx annotated with use client
  • All of the above are just the basic features of a modern Next.js application. You can and should make a deeper deep dive into the official docs to learn about other usefull features and guidelines on how to build with this stack.

Architecture - Auth Layer

For authentication and authorization we choose Clerk for rapid development and easy of use. In this template Auth is configured out-of-the-box with some defaults that can be modified.

Architecture - Data Layer

A Neon↗ Postrges Database is required, but local development can be done via a local instance through Docker. Drizzle↗ is the ORM used to manage the the DB and this is the case for several reasons:

  • Can handle almost every relational databases, so switching can be done pretty easily.
  • Easy way to handle schema push, migrations and seeding of the DB

Resources