DEV Community

Ravi
Ravi

Posted on

I made a template for building full-stack app from the stack I keep reusing

Over the past few years I have had to build a few different apps (having no formal CS background), usually some version of a full-stack product with an API, web UI, CLI tooling, packaging, etc.

Using the tech stack and the knowledge acquired during the last few years, I have tried to ask Claude to make a reuseable template based on that. Putting it out here, in case it helps anyone.

OpenProductKit: github.com/ravipurohit1991/OpenProductKit

It’s a Copier template that generates a product repo with:

  • FastAPI backend
  • React/Vite frontend
  • Typer CLI
  • pywebview desktop app
  • plugin API
  • licensing hooks
  • generated OpenAPI TypeScript client
  • an Agent.md file so any AI agent can fill in your app idea into the template

The main idea is to keep the business logic in a framework-free Python core (this was a personal choice), and then build the web, CLI, and desktop surfaces around that same core.

It is still early, and I’m sure there are things that are overbuilt, missing, or just based too much on my own way of working.

I would love feedback from people who have built/shipped full-stack apps:

  • does this structure feel useful?
  • what would you change based on your experience?

Top comments (2)

Collapse
 
ryan_mingus_61aef6352cc87 profile image
Ryan Mingus

Interesting, definitely i have in the past used similar structure or architecture. one thing I would do differently is to host the web frontend (react) directly on the FastAPI (the same instance of the backend worker) via static build files. That worked out great interms of maintaining the software. Otherwise your structure sounds solid. great job

Collapse
 
ravipurohit1991 profile image
Ravi

Great, thanks for the comment. I have also in the past used FastAPI to route the static frontend. However when we had to scale for different clients and client side rendering, this turned out to be a pain and security issue. I agree that its a cleaner approach for sure. But for development, particularly what the above library tries to make it easy. The current approach is the one I am more comfortable and confident about.
For sure, the users/devs can then just expose the compiled frontend via SPA hosting directly from the fastapi worker.