💭 Discussion: Modernize Architecture - Monorepo with React + TypeScript

[CodeByStella]

Current state

The project uses:

• ✅ Vite (frontend build tool)
• ✅ Express (backend server)
• ⚠️ Vanilla JavaScript (frontend)
• ⚠️ Mixed structure: backend code (controllers/, middleware/, models/) and frontend code (js/, css/) are both in src/

Concerns

1. Code organization: Backend and frontend are mixed in src/, which can confuse contributors.
2. No type safety: JavaScript-only increases runtime error risk.
3. Scalability: Vanilla JS becomes harder to maintain as the app grows.
4. Developer experience: TypeScript improves IDE support and catches errors early.

Proposed architecture

Convert to a monorepo with clear separation:

codestream/
├── packages/
│   ├── frontend/          # React + Vite + TypeScript
│   │   ├── src/
│   │   │   ├── components/
│   │   │   ├── pages/
│   │   │   ├── hooks/
│   │   │   └── utils/
│   │   ├── package.json
│   │   └── vite.config.ts
│   │
│   └── backend/           # Express + TypeScript
│       ├── src/
│       │   ├── controllers/
│       │   ├── middleware/
│       │   ├── models/
│       │   ├── routes/
│       │   └── server.ts
│       └── package.json
│
├── package.json           # Root workspace (npm/yarn workspaces)
└── tsconfig.json          # Shared TypeScript config

Benefits

1. Clear separation: Backend and frontend are isolated.
2. Type safety: TypeScript reduces bugs and improves maintainability.
3. Modern frontend: React improves component reusability and state management.
4. Better DX: TypeScript provides autocomplete, refactoring, and error detection.
5. Scalability: Easier to add features and onboard contributors.
6. Monorepo: Shared types/configs, unified tooling, easier dependency management.

Migration considerations

• Breaking change: Requires refactoring existing code.
• Learning curve: Contributors need React/TypeScript familiarity.
• Timeline: Can be done incrementally (e.g., backend first, then frontend).

Questions for discussion

1. Is the team open to this architectural change?
2. Should we migrate incrementally or all at once?
3. Any concerns about the proposed structure?
4. Are there specific features/functionality we should prioritize preserving?

Next steps (if approved)

• Set up monorepo structure
• Migrate backend to TypeScript
• Create React + TypeScript frontend
• Convert existing functionality
• Update documentation and setup guides

---

What are your thoughts? Should we proceed with this modernization, or discuss alternatives?

[CodeByStella]

@gbowne1 @sisyphus-42 @djnadackal @Ved178

[gbowne1]

@CodeByStella

I agree with separate frontend code from backend code, but I disagree with making this a React project especially with Typescript.

I also really don't want another React project either. I have at least 5 others.

Perhaps the better task would be separating the frontend code here from the backend code.

However we still have 8-10 open PRs to get through before making any significant changes

Thanks though

[CodeByStella]

@gbowne1
Thanks for considering. I think typescript will help this project much.
Anyway according this needa refactor entire project, it will be better to do this after merge all pr.

[CodeByStella]

I understand, thank you for the explaining.

would you have any interest in resuming work on the projects like ReactSocialNetwork further? if so, I will be happy to discuss ideas or potential next steps.

Also, do you have any preferred communication space beyond github? I don't think gitfub is a good place to discuss things that are not related to main topic.

[gbowne1]

Yes, those projects need completed. The two main contributors I had, stopped contributing to RSN.

I prefer using Discussion tab to talk about ideas, bugs, features, etc.

[CodeByStella]

Okay, I'd like to contribute on the project also. And can I ask if any contract work is available? Is there any business project that you are planing?

[gbowne1]

No, there isn't. This and any of my other projects are for fun open source projects for people to contribute to so that they improve. These aren't paid projects. I let people contribute their own design and layout because they enjoy programming and solving problem because they're fun and hopefully people will find them useful.

This particular project for a programming stream platform will be free to use once its MVP and useable and unlike the two main stream platforms are able to be fixed by people that use it.

You're welcome to contribute to this or any of my other projects https://github.com/gbowne1

[CodeByStella]

Hmm, I see. but it seems I still need to focus on making ends meet, lol.

[shishir-21]

@gbowne1
@CodeByStella

The proposed structure looks clean and well organized, especially the clear separation between frontend and backend. From a long term perspective, this kind of modularity definitely helps with maintainability.

One additional small thought for the future: it might be helpful to reserve a minimal database or data-layer file/config early on (even as a placeholder). As the project grows, introducing a DB later can become more difficult, so having a basic structure in place could reduce friction without adding much complexity now.

[gbowne1]

@shishir-21

I really only want to separate the frontend and backend code.

Let's wait for everything to land before making serious changes beyond structure. Theres a crap load of incoming to get through.

I also dont think we really need types, and if we do very few that something like Typescript provides.

[shishir-21]

@gbowne1

Makes sense, thanks for clarifying.
Focusing on separating frontend and backend first sounds right. Happy to help

[gbowne1]

Yeah, let's just focus on reviewing what we have and landing those. If someone is willing to stick with this project a long while I'll invite them as a collaborator which will somewhat improve the review and triage process.

Any idea which of the dozen PRs should land first @shishir-21 said for the one that needs to be closed and issues reopened as separate items?

[gbowne1]

I'll be a bit less apprehensive about merging once the CI workflow PR and some tests land.
Nobody's written tests but theres a issue for it. Vitest for now.

Ensure that this runs in node 20/22/24