Eventually refactor to a new stack

[gbowne1]

Should we eventually refactor to a new stack. This won't happen right away!

My thoughts:

• Next.js
• Prisma
• Redis
• TypeScript instead of JavaScript
• TailwindCSS / TailwindUI or NextUI or ChakraUI or MUI
• Redux

@LOGESH-B @k-deepak04 @shyamtawli @Vishwanath760970

[Vishwanath760970]

@gbowne1 Yeah I agree with implementing,
Next.js
TypeScript instead of JavaScript
MUI
Redux

Not sure about Prisma/ Redis much as I haven't worked with them.

[gbowne1]

Great thanks for your input on a potential future refactor.

[LOGESH-B]

Hii @gbowne1
It's ok, but why you thought of this. Is there any reasons?

[gbowne1]

It's only a thought I had at this particular point in time. I don't have any particular reasons other than just a overall developer experience improvement. There's no particular issues we have right now that we can't solve. but I am saying for the future we can improve the codebase by such a refactor. We have a long ways to go before we are even there though.

I would also only suggest this once we get to a 1.0 stage. Doing so may also improve deployability somewhat.

[shyamtawli]

Hey, I have no experience in Next but want to explore it so it will be good learn by doing for me.

[gbowne1]

@ratishjain12 @BlackBond06 @dimassibassem @alienqqe @jchansen925 @kabszac @Jonnie-Dev @neeravbhaskarla @shivm29 @Piyush-Deshmukh @khalil-p @javadkhangurbanov @realrohitgurav @atharvarekhawar @Mayor-Rhymes @shyamtawli @777Prabhjot

[ratishjain12]

Yeah I agree using tailwind will be much more better and learning nextjs will also be a great thing

[gbowne1]

Tailwind can be used alongside MUI to enhance what MUI already gives us.

I really don't mind doing the upgrades mentioned in todays issue #162 but, it must be decided upon as a group. now that we have more active developers working on this project.

Keep in mind I have no/limited experience with Typescript, while I know most types pretty well. I still have not had time to venture into Typescript 100%. We have prop-types installed because I don't think we really need every single type that Typescript offers, if we only need a few types, I don't see the benefit.. although I agree it would benefit the project's long term.

I think this sort of upgrade should happen once we get to MVP or an early rc/alpha/beta, and lets focus on getting the features in before we make major changes.

[dimassibassem]

Regarding TypeScript, I agree that its implementation could significantly benefit the project's long-term maintainability and type safety. It's worth noting that TypeScript's type system can greatly enhance the development process by catching potential issues at compile-time and providing improved code documentation. While I have some familiarity with TypeScript's core concepts, I understand your point about the learning curve and the decision to focus on features first.

I also see the potential synergy between Tailwind CSS and MUI, as combining their strengths could provide a more tailored and enhanced user interface.

As we have a growing number of active developers, it's a great opportunity to collectively decide on the timing and approach for these upgrades. I agree with your suggestion of prioritizing feature development in the immediate term while keeping the upgrade discussion in mind for a more mature stage, like MVP or a later development phase.

[gbowne1]

yeah, I mean it's a great idea overall and I am on board with that idea and we will do it.. but lets get this to a more mature state. We don't even have tests yet. The only one we have was shipped with CRA. App.test.js and it already fails.

If we do add Tailwind CSS to the current stack, there can be some real benefits to both in the same project. It's already been done in a large number of MUI projects and the ones I have seen using it are solid, so we should add that to the ASAP roadmap.

I fully intend on doing releases at that point using the GitHub workflow for that. It's just important that since there are a number of developers working on this, that this be discussed as a whole. Our developers, maintainer, owner, collaborators have a wide array of experiences.

If we are just trying to catch errors, we really need to invest time in building e2e, unit and integration tests.

If someone wanted to, they could really include a future branch that would implement the stack.

There's some other mid-term things I wanna do too, like Dockerization, K8s, .devcontainers...

[gbowne1]

That being said we also are not fully using what React 18 itself comes with out of the box. More API's, more hooks, etc.

Thanks to in large part to @LOGESH-B for starting the backend development.

We still have a whole page of issues and TODO's and a couple bugs to get through and I would like to have the number of issues (26) at this point.. in https://github.com/gbowne1/codebooker/issues/ and a lot of them have been around quite a while/stale.

I may eventually convert this repository project into a GitHub organization, so that we can build some tooling, etc. for the project. And I will do that when the community decides that's a great move to make. It would give us more features here and allow us to create libraries, helpers, utilities, etc.

I have physical rack space here so hosting won't be an issue at all, and am still working on a phsyical database server we can use in both dev and prod.

Either way, all of you have had great ideas and have helped out so much I would like to thank everyone who has gotten us to this point.

[BlackBond06]

It's really a great suggestion for the long term, however, I think adding features to the app should be our priority for now. Thank you @dimassibassem

[gbowne1]

Also once we get to it, this task should be spread across a few developers minimum to reduce workload.

We also should take some sort of census here. Who here does frontend, backend, fullstack, middleware and QA // QC?

My priorities are getting in features and testing. Lately some breaking changes have slipped in which could be helped by some testing. In browser testing is fine, and everyone should be testing this in the browser, but is not a long term solution, nor is it an all in all best practice, becuase you really need e2e, unit and integration tests and some coverage.