This stack is a cloned and modified version of GitHub user Rykuno's TofeStack.
A scalable, testable, extensible, template for Sveltekit.
Sveltekit is awesome, but sometimes you need a bit more capability in the backend than what frameworks like NextJS & Sveltekit can deliver.
To remedy this, I've attached a fully fleshed out backend to run on the Sveltekit process and forward all API requests to it and paired it with some architectural patterns.
/api/[...slugs]
import app from '$lib/api';
import type { RequestHandler } from '@sveltejs/kit';
export const GET: RequestHandler = ({ request }) => app.fetch(request);
export const PUT: RequestHandler = ({ request }) => app.fetch(request);
export const DELETE: RequestHandler = ({ request }) => app.fetch(request);
export const POST: RequestHandler = ({ request }) => app.fetch(request);
export const fallback: RequestHandler = ({ request }) => app.fetch(request);
.env.example
file and rename to .env
true
in the .env
for this first run.pnpm install
citext
is being used to allow for case-insensitive string matching. To install the extension run CREATE EXTENSION IF NOT EXISTS citext;
or add inside an additional drizzle SQL file for startup to use.pnpm initialize
(this will start the docker-compose and run the initial database migration.)pnpm dev
false
in the .env
after initial set up.No additional setup is required, zero api keys, zero services to signup for, zero cost.
This is not supposed to serve as an all batteries included "production boilerplate" with 200 useless sponsored features that get in your way. Templates that do this are ANYTHING but "production" and "quick start".
This is stack is designed to be library agnostic. The philosophy here is to boostrap the concrete, repetitive, and time-consuming tasks that every application will need regardless of what you're building.
So - fork this repo, add your favorite libraries, and build out your own "more opinionated" personal template tailored to you!
I'm mostly un-opinionated of what technology or libraries someone uses. Wanna uwu'ify your entire app? Go for it.
That being said, there are some libraries that embody my philosophies of building software more than others,
There are a few popular architectures for structuring backends. Technical, Onion, DDD, VSA, and the list goes on. I almost always choose to start with Technical and let the project naturally evolve into one of the others as complexity grows.
controllers - Responsible for routing requests
services - Responsible for handling business logic.
repositories - Responsible for retrieving and storing data.
infrastructure - Handles the implementation of external services or backend operations.
middleware - Middlware our request router is responsible for handling.
providers - Injectable services
dtos - Data Transfer Objects (DTOs) are used to define the shape of data that is passed.
common - Anything commonly shared throughout the backend
You might notice how each file in the backend is postfixed with its architectural type(e.g. iam.service.ts
). This allows
us to easily reorganize the folder structure to suite a different architecture pattern if the domain becomes more complex.
For example, if you want to group folders by domain(DDD), you simply drag and drop all related files to that folder.
āāā events/
āāā events.controller.ts
āāā events.service.ts
āāā events.repository.ts
Testing probably isn't first and foremost when creating an app. That's fine. You should not be spending time writing tests if your app is mutable.
BUT, a good stack should be testable when the time to solidify a codebase arrives. I created this stack with that principle in mind. I've provided a examples of how to write these tests under authentication.service.test.ts
or users.service.test.ts