LY Fullstack: A TypeScript Monorepo Foundation That Lets Frontend Devs Ship Complete Apps

Don't know backend, only know TypeScript, want to build a complete project independently? This full-stack foundation is made for frontend developers

No fluff, straight to the goods. https://liangy0323.github.io/ly-fullstack

Have you ever run into these situations?

Someone asked me to build a mini-program. The frontend pages are no problem, but I don't know backend, so I didn't dare take the job.

Someone asked me to build a B2B corporate site. I can write the pages, but there's no one to do the backend and APIs, so in the end I still couldn't take it.

My boss asked me to independently complete a "business C-end + admin panel + server-side" system, but I only know Vue or React.

AI can help me generate a few APIs, but I have no real grasp of how to design the database, how JWT authentication works, how to control permissions, or where the code should go.

What you're missing might not be frontend skills.

What you're missing is a full-stack project that already has the backend fundamentals running, and that a frontend developer can read, understand, and dare to continue building on.

Don't worry, this is exactly the problem LY Fullstack aims to solve.

It already wires together the admin panel, admin API, default C-end API, PostgreSQL database, login authentication, RBAC permissions, dynamic menus, testing, CI, and local initialization workflow. You no longer need to start from an empty directory and research "how exactly should a backend project be structured" — you can start directly from your own business logic.

Only know TypeScript? No problem.

The C-end can continue using the Vue, React, Nuxt, mini-program, or other tech stack you're familiar with; the repository won't define a specific C-end product for you, but it provides a default C-end API built on NestJS, serving as the server-side starting point when adding real business modules. Frontend and backend still use the same language, so you can follow a real, runnable business chain, developing while understanding the backend.

More importantly, it's not just developer-friendly — it's also an AI-friendly engineering foundation.

The repository already includes AGENTS.md and over a dozen development specifications. How directories are divided, where APIs go, how to modify the database, how to override Element Plus themes, and what checks a feature must pass before completion — all of these rules are already written down.

You don't need to let AI run wild in an empty repository; instead, you let it read the rules first, then work within the boundaries the project has already established.

You are responsible for deciding what to build; the foundation tells AI how to build it.

This won't turn you into a senior backend engineer overnight, but it's enough to let a frontend developer familiar with TypeScript confidently take the first step into full-stack development.

Project address: github.com/liangy0323/ly-fullstack

It's not a backend system with all business logic pre-built

Let's be clear up front: LY Fullstack is not a backend management system with all business functions pre-built; it's an engineering foundation that completes the full-stack infrastructure for you in advance.

How to set up the server, how to build the admin panel, how to do login authentication, how users, roles, and menus relate, how to initialize the database, how to handle requests and errors — these fundamental modules that every project repeats are already prepared in the repository.

On top of this foundation, you can directly develop your own mini-program, corporate site, personal product, or other C-end business, then add corresponding management modules for the real business, without having to build the server-side and admin panel infrastructure from scratch for every single project.

What it truly saves isn't the time to write a few pages, but the repetitive, tedious, and error-prone engineering setup time from an empty directory to the point where you can "finally start developing business logic."

That said, a generic foundation doesn't mean a bare-bones project.

LY Fullstack's admin UI is not sloppy at all. The login page, workspace, dark/light themes, charts, forms, tables, dialogs, and feedback states all follow a unified visual specification — it's not a set of default Element Plus pages thrown together casually.

If your project is itself a frontend-backend integrated management system and doesn't need additional independent C-ends like mini-programs or corporate sites, then the existing admin and admin-api can also be used out of the box. Connect your business tables and business modules, and you can jump straight into feature development.

It can serve as the management foundation behind a C-end business, or directly as the starting point for a backend management business project.

Let's see what it looks like now

This is LY Fullstack's current dark-mode workspace:

The light theme has also been separately adapted, not just a simple swap of black backgrounds for white:

I know, GitHub is never short of admin panel screenshots that "look complete."

So this time, what I care about more isn't how many menu items there are, but whether the processes behind the screenshots are real.

The repository now has these capabilities running:

Admin login, session recovery, logout, and password change.
RBAC permission loop composed of users, roles, and menus.
Users bound to roles, roles assigned menu and button permissions.
Database menus driving the frontend sidebar and dynamic routes.
Real CRUD for users, roles, and menus.
PostgreSQL database migration, initialization, and seed data.
Health check, public dictionary, and public config reads for the default C-end API.
Unit tests, Playwright browser tests, and GitHub Actions CI.
Dark/light themes, unified feedback, version detection, and update notifications.

The statistics on the workspace are just for UI demonstration; user, role, and menu management come from real APIs and a real database.

What a frontend developer can actually do with it

Suppose you land a corporate website project.

The C-end might use Nuxt, or just plain Vue; the website needs to display products, articles, and inquiries, and behind it needs an admin panel to maintain this data.

If you start from an empty directory, the first step isn't even writing business logic — it's setting up the framework and making tech choices.

For the frontend, you quickly pick the Vue you're familiar with, but when it comes to the server framework, database, ORM, and project structure, you realize the only things you're truly confident in are Vue and TypeScript. Even if you finally decide to use NestJS, which is also TypeScript-based, there's still an entire engineering chain to build from scratch:

How to organize the frontend and backend project structure
How to divide server-side modules
How admins log in
How to verify tokens
How users and roles relate
How to control menu permissions
How to create tables and run database migrations
How to return API errors uniformly
How to show unified prompts when frontend requests fail
How to initialize the project on a different machine

By the time all this is done, you might not have written a single line of the actual "product management" or "inquiry management" logic.

What LY Fullstack aims to eliminate is precisely this part — the work that every project repeats and that's easy to get wrong the first time.

After getting the repository, you can keep the existing admin, admin-api, and default api, then directly add your own C-end business modules in apps/api; only when the business genuinely requires a new independent deployment boundary would you use pnpm new:server to create another server project. The client side continues to choose Nuxt, Next.js, mini-programs, or other tech stacks based on the real scenario.

It doesn't guess in advance what your C-end will be.

Because the page forms and business models of personal products, corporate sites, mini-programs, and content sites are completely different, forcing a so-called "universal C-end product" would most likely just be another empty shell you'd need to delete.

But "not defining the C-end" doesn't mean providing no C-end server-side foundation at all. The current apps/api deliberately only implements health checks, public dictionary, and public config reads, without fabricating specific business entities like end users, orders, or content. Its value isn't deciding your product for you, but using these few basic APIs to establish a reusable implementation paradigm: app config and safe startup, NestJS module organization, Controller and Service layering, Prisma data access, cross-end safe types, and corresponding tests. Combined with the development constraints in the repository, adding real C-end business later has a clear landing point, making it less likely to bloat and lose boundaries as features grow.

But no matter what the C-end is, admin login, users, roles, permissions, database, and backend CRUD almost always need to be done again.

LY Fullstack has already built this part into a reusable management core.

Why it's more comfortable for frontend developers

I'm not saying that as long as you know TypeScript, you can completely ignore understanding databases, security, and backend design.

That kind of promise is irresponsible.

What LY Fullstack truly lowers is the barrier to start practicing.

Frontend developers don't need to switch to a different language first, nor do they need to master a vast backend ecosystem before writing their first API endpoint. Both frontend and backend use TypeScript, so you can first use a familiar language to understand how a request enters a Controller, how business logic lands in a Service, how data is handed to Prisma, and then gradually understand authentication, permissions, and database transactions.

Many concepts aren't completely foreign:

Things familiar to frontend devs	Things to further understand in the project
Page routing and route guards	Backend Controller and Guard
Components and Composables	Module, Service, and Dependency Injection
TypeScript types	DTOs, API contracts, and DB model boundaries
Axios request wrappers	Unified responses, error handling, and auth checks
Frontend tooling	Migration, seed, testing, CI, and deployment

They are certainly not the same thing, but using the same language eliminates one drastic mental and toolchain switch.

More importantly, what you're facing isn't a pile of disconnected tutorial code, but a chain that's already connected:

Page Form
  → Frontend Service
  → HTTP API
  → NestJS Controller
  → Business Service
  → Prisma
  → PostgreSQL

Learning along a real chain makes it easier to build a complete understanding than first reading dozens of isolated concepts and then trying to piece them together.

LY Fullstack isn't about letting frontend devs bypass the backend, but about letting them start from the TypeScript they know best and truly walk into the backend.

I didn't want to build another demo-only template

This project wasn't thrown together just to write an article.

Its first batch of engineering experience didn't come from imagining a scaffold, but from a project where I independently completed product design, frontend development, and backend development with the help of AI, and actually delivered it. Before making it public, I removed the client name, business data, images, domain, and all proprietary logic, keeping only the parts that were repeatedly used in real development:

NestJS + Fastify server infrastructure.
PostgreSQL + Prisma database workflow.
Login, JWT, account status re-check, and password change.
Vue admin panel's request layer, routing, CRUD, and feedback patterns.
pnpm Monorepo, testing, CI, and local initialization workflow.
Frontend, backend, database, and AI collaboration rules.

The extraction process wasn't just copy-paste either.

This repository overturned quite a few decisions that seemed "more complete" midway:

Originally considered only putting an empty C-end API with no real capability, later adjusted it to be a default business API foundation: keeping general read capabilities and complete implementation specs, but not pre-building any specific C-end business.
Originally considered maintaining both Vue and React Admin simultaneously, later decided to keep only one Vue implementation that could be seriously maintained.
Originally wanted to extract Axios into a cross-framework sub-package, later realized there was no second real consumer — it was just over-engineering.
Originally referenced existing admin UIs, eventually cleared them all out and rebuilt its own theme and page style.

What truly matters for a foundation isn't how many things it pre-builds that might be used in the future, but knowing which capabilities should stay and which abstractions don't yet have the right to exist.

Three commands to get the project running

After preparing Node.js, pnpm, and a working PostgreSQL 17 environment locally:

pnpm install
pnpm setup
pnpm dev

pnpm install installs dependencies and won't secretly create a database for you.

PostgreSQL 17 can be installed directly on your machine, or the project can start it via Docker Compose — just pick one method. If your machine has neither a usable PostgreSQL nor Docker installed, the initialization process cannot complete.

pnpm setup will ask for the PostgreSQL password, database name, and initial admin password. It will preferentially reuse PostgreSQL on local 127.0.0.1:5432; if no local service is detected but Docker Compose is available, it will automatically start the project's PostgreSQL 17 container. Once the database is ready, the script creates the database, runs migrations, and initializes table structures and basic RBAC data.

pnpm dev lets you choose which apps to start.

After starting, open http://localhost:8081 and log in with admin and the password you just set.

These steps seem simple, but they solve the problems that most easily discourage newcomers in full-stack projects: where exactly to put environment variables, how to create the database for the first time, how to sync table structures, where the initial admin comes from, and why it won't run on a different machine.

When these processes can be executed repeatedly, you can finally focus your attention back on the business itself.

Why no microservices yet

If you just want to complete your first full-stack project, you can actually skip this section.

But since it's an engineering foundation intended for long-term maintenance, I still need to clarify its architectural boundaries.

The current version uses an architecture of Monorepo managing multiple apps, with each service internally using a modular monolith — not microservices.

The admin-api and default api in the repository are two NestJS applications that can be started, configured, and deployed independently. admin-api handles admin login, RBAC, and system management, while api provides the server-side foundation for future real C-end business; the two maintain authentication and application boundaries, not directly mixing admin sessions into the C-end.

But "having multiple independently runnable applications" doesn't mean microservices have been adopted. Each service internally still organizes related capabilities according to NestJS modules, and currently no microservice governance facilities like API gateways, service registration and discovery, inter-service messaging, distributed transactions, or tracing have been introduced. This structure avoids piling all backend responsibilities into a single process, without needing to bear the complexity of a distributed system before the business scale warrants it.

For individual developers, small teams, and a large number of small-to-medium projects, the real problem is usually not "services aren't split enough," but:

Are login and permissions reliable?
Can the database migrate stably?
Is there a unified boundary for where code goes?
Can the project run on a machine other than the author's?
Have testing, CI, and deployment formed a closed loop?

If these problems aren't solved, splitting into microservices first won't automatically make the project more advanced; it will just turn a local call into a network call and add a whole set of distributed system problems to deal with.

NestJS itself supports microservices. In the future, LY Fullstack will also separately plan a microservices version, but it won't forcibly shatter the current version aimed at individuals, small teams, and small-to-medium businesses just to appear "architecturally advanced."

Architecture isn't more professional just because it's heavier. Using a sufficiently simple solution to solve problems at the current scale is itself professional judgment.

What it has done, and what it hasn't

Currently, login, RBAC, dynamic menus, system management, theme system, database initialization, unit tests, browser tests, CI, and deployment docs are in the repository, and v0.1.0 has been released.

But it's not a finished product system with all business logic done.

It hasn't pre-built a mall, content management, multi-tenancy, or workflows for you, nor is there a public online demo — the server isn't ready yet, and I won't write down planned capabilities as if they're already complete.

It's more like a site with utilities connected and the foundation poured.

You no longer have to start digging from login, permissions, database, and engineering config, but whether you ultimately build a corporate site, mini-program, personal product, or internal tool still depends on your own business.

This is also what I believe is the most appropriate boundary for an open-source foundation:

Do well the parts that all projects are likely to repeat, and leave the parts that only real business can decide to the user.

Finally

LY Fullstack isn't meant to prove that "frontend devs can casually write backend too."

On the contrary, after truly completing a full project once, you'll start to understand: login isn't just issuing a token, permissions aren't just hiding buttons, a database isn't just creating a few tables, and deployment isn't just uploading dist to a server.

But this knowledge doesn't have to be learned all at once before you start.

If you're already familiar with Vue and TypeScript, want to independently build a complete project, but have never known where to start with the backend, then this project is prepared for you.

You can first get it running, see how a single login goes through the frontend, API, Guard, Service, and database; then try adding a business module of your own.

Going from "can write pages" to "can deliver a complete project" — what's missing in between often isn't another language.

What's missing is a path you can truly walk all the way through.

Project address:

github.com/liangy0323/ly-fullstack

If you run into problems when actually running it, feel free to submit an Issue. Whether an open-source project is truly beginner-friendly shouldn't be announced by the author, but verified by the people encountering it for the first time.

Next up

The next article won't rush into abstract architecture.

We'll directly stand from a frontend developer's perspective and walk through the complete process:

After getting LY Fullstack, how do you add your first full-stack business module?

From database tables and backend APIs to admin pages, connecting a real business chain. Once you've walked through this yourself, looking back to understand Monorepo, module boundaries, and type contracts will be much clearer than memorizing concepts first.