Tech stack conversation.

[Philip-Clark]

Feel free to suggest a tech stack.

Update: This discussion can begin in earnest now that the project has been selected.

[MarchandMD]

+1 for a RoR backend

[CChiu28]

Recommending React(Vite)/Typescript/Tailwind for frontend

[Lofty-Brambles]

I'm sure vite is a cool choice. But we should definitely be adding something more developed.
Vite-plugin-ssr is definitely a solid choice, not only does it pre-render content for SEO, but it can also take a lot of care about the rest of the issues that next deals with.
I'll lead an update on this once the MVP gets finalized though, as we need some key questions answered.

[Lofty-Brambles]

As for tailwind, we are surely using an structural library and not writing off-the-screen classes like a maniac right? Off the top of my head we have two options, Daisy UI and Material UI. Off the top of my head, Daisy offers simple intellisense too, and also is easy enough to work with, so it's the better option for me.

[justEstif]

Radix ui has been growing in popularity. this(not sure it has a name yet) combines radix ui with tailwind. Might be work considering. Seems as well.

[Lofty-Brambles]

Yea, radixUI is cool enough, but daisy has a ton more options and is much more mature.. Either ways, I'm fine with any.

[ManorSailor]

I haven't been keeping up with discussion on Discord & here, a lot has happened in my absence. Anyways. In PR #25, it seems we have moved forward with DaisyUI. I've also come across Preline, a UI library with template style approach. Any thoughts on Preline?
Additionally, the PR is missing prettier-plugin-tailwindcss for sorting class names in the correct order. Despite using a UI library, we may still want to customize it using tailwind classes. In that scenario, having the classes sorted in the correct order would be beneficial.

[justEstif]

Recommending Express + Prisma(SQL) if we aren't going with rails.

[MarchandMD]

ooh, yeah, i'm super ok with Express too; would be great to work on a Node project

[Philip-Clark]

It hasn't been set in stone yet, but I think the general consensus is that the BE will be Ruby. This is largely because TOP teaches BE first in the Ruby path, and last in the Node path. Given that, more people from both paths can work on more parts if the backend is Ruby.

But definitely keep the ideas flowing. If we go with Node as BE, these comments will be useful.

[rcamach7]

Frontend Tech Stack:

• NextJS (React Framework)
  • Native routing support
  • Organized project structure for better code understanding
  • Easy external backend integration
  • Will offer NextAuth for easy user authentication
  • Built-in optimizations
  • Cons: Learning curve
  • Alternatives: Vite, Remix
• Material UI (React Component Library)
  • Speeds up development with pre-built components
  • Consistent component design
  • Responsive
  • Cons: Learning curve, design constraints
  • Alternatives: TailwindCSS, Bootstrap, ChakraUI
• State Management: React Context
  • Easy to set up
  • Cons: re-rendering concerns, boilerplate code for complex state updates
  • Alternatives: Redux (might be overkill for small apps)
• Testing: … (I don’t have deep experience here)

[Lofty-Brambles]

I totally see your point. I think this is where we decide what works best for our needs. Do we go for a super customizable build tool, or a framework with core features built in? Keep in mind, though, more customization can also mean a bigger learning curve and more complexity. Since we're just building a CRUD app, maybe we might not need all that extra customization.

Yep, which's why I'm suggesting vite-plugin-ssr. Not only is it vite-based, it offers all the goodness of next, like file system routing, and is easy to integrate into a rails backend. Next pushes serverless infrastructure so harshly, that it is a pain (and I don't even know if it's possible) to make a rails backend integrate into it.

[rcamach7]

Yep, which's why I'm suggesting vite-plugin-ssr. Not only is it vite-based, it offers all the goodness of next, like file system routing, and is easy to integrate into a rails backend. Next pushes serverless infrastructure so harshly, that it is a pain (and I don't even know if it's possible) to make a rails backend integrate into it.

Vite is just a build tool and doesn't offer as much as Next provides natively (this can be a good thing in many situations). Plus, it's been around a bit longer, so there are loads of plugins and libraries to help you out. It also integrates with any backend, regardless what languages or frameworks they're built with.

[fcasibu]

Storybook for visual testing and a more streamlined way to test components in isolation (should be enough, it's also super easy to write stories). I'm not totally against testing with jest/rtl or even e2e tests, I'll go with the majority, but personally 🙅‍♂️

[Lofty-Brambles]

Did you bother reading vite-plugin-ssr docs, or is this just.. assuming what it does? It even offers a neat table to show it's features when compared to Next on what it tries to fix. What is Next other than a glorified build tool with a ton more features?
A lot more people are familiar with some solution that's more vanilla react, which's much easier to use.

[crespire]

* **Testing**: … (I don’t have deep experience here)

For the Rails side, I would recommend RSpec set up with Faker and focusing on request tests. On the front end side, I am less experienced. For a similiar project, I ended up using Cypress e2e test suites but mocking the entire backend in the suite. I don't recommend this route, as it's very brittle.

[taladan]

I have no suggestions as far as a tech stack goes as I don't have a deep enough knowledge about everything that is available. I am currently in the ruby section of the course so, if we go with ROR, technically I should be able to at least play like I'm helping with the back end stuff. What is our deadline for deciding?

[justEstif]

According to the timeline, April 12. I don't think it is a strict deadline however.

[Ananth-Adhikarla]

I think Biff said by mid or end of this week to finalize and close it

[MarchandMD]

Do we need to have a conversation RE versions of software? I.E. Rails 5 v rails 6 v Rails 7. Or is it best to stick with the current stable curriculum versions?

[crespire]

I think sticking with the stable versions of the tools should be fine. That would mean the latest Rails 7, latest React, and all the libraries that support those versions.

[crespire]

A few comments re: tech stack and library choices.

Authorization on the API

There are a lot of excellent authorization gems out there, and the product should probably use one of those rather than write something from scratch. I've worked a lot with Pundit, but CanCanCan is also an option. User permissions like being able to delete, edit, update, invite other users, etc to a pantry should be built on top of an authorization system based on these gems. We should probably decide on an option before the project gets underway.

Front end state and data management

We should also talk about how we will manage state on the front end application and how it will interact/interface with the backend. There are a lot of React library options for this, some more fully featured than others.

• Zustand is the "it girl" of the moment, but I have no opinion on it, other than it seems very light and very focused on client side. It would likely be useful to use it in conjunction with React Query.
• I've personally only used React Query/Tanstack Query, and I used it with vanilla React state management to get what I wanted done. Pairing with Zustand might give us all the functionality we need. It is also possible to pair React Query with React's native state management systems (reducers, useState, and useContext) to get an acceptable result.
• Redux with redux toolkit (RTK) also provides a similiar kind of functionality, but it's what I would consider a "full fat" library. It does both client state management through stores, and client data management via RTK. This is a popular library, with lots of resources out there, so even though I think it might be a bit overkill, I would recommend we at least consider it.

Front end UI (and component?) library

I'm a big fan of TailwindCSS plus DaisyUI.

Open to thoughts, criticisms and other input.

[Lofty-Brambles]

vite-plugin-ssr is a namesake for a ton of QoL features. You can definitely stick to CSR and only pre-render a few pages as necessary. It has file system routing and opt in features, as necessary.
You can definitely add anything you prefer and use much more vanilla react than you'd use than next.

https://vite-plugin-ssr.com/render-modes CSR.
https://vite-plugin-ssr.com/prerender-config#partial Partial prerendering
https://vite-plugin-ssr.com/filesystem-routing File system routing
https://vite-plugin-ssr.com/nextjs-comparison Comparison w/ Next.

Plus, the rest of their documentation is very nice and terse.

[Lofty-Brambles]

Do you have any thoughts about what we go with for Authentication? Devise seems pretty annoying with a separate front end + JWT stuff. I feel like there's probably something we could do with a provider (Auth0 maybe?), but I don't have direct experience with that.

I do understand that Auth0 is very easy to integrate and free up to 8k users, but I've only used it with Node.
Does https://auth0.com/docs/quickstart/backend/rails sound handy?
Integrating into react is as simple as a ctx provider: https://auth0.com/docs/quickstart/spa/react
@JoshDevHub

[crespire]

Do you have any thoughts about what we go with for Authentication? Devise seems pretty annoying with a separate front end + JWT stuff. I feel like there's probably something we could do with a provider (Auth0 maybe?), but I don't have direct experience with that.

I think auth0 is an excellent option. Devise is tough in this project because we're not using the Rails frontend. My only hesitation is that Auth0 seems to offer authorization at the token level, but I think we should handle authorization in-app via Pundit or CanCanCan, rather than try to tie authorization in with authentication via Auth0.

[crespire]

vite-plugin-ssr is a namesake for a ton of QoL features. You can definitely stick to CSR and only pre-render a few pages as necessary. It has file system routing and opt in features, as necessary. You can definitely add anything you prefer and use much more vanilla react than you'd use than next.

https://vite-plugin-ssr.com/render-modes CSR. https://vite-plugin-ssr.com/prerender-config#partial Partial prerendering https://vite-plugin-ssr.com/filesystem-routing File system routing https://vite-plugin-ssr.com/nextjs-comparison Comparison w/ Next.

Plus, the rest of their documentation is very nice and terse.

I don't think terse documentation is a boon for a project of this nature. I don't know, I just don't see the net positive here of going with something like vite-plugin-ssr. Not a blocker for me but I just have some reservations about using it for the sake of using it. I am happy to leave the decision to the rest of the team.

[MarchandMD]

Do you have any thoughts about what we go with for Authentication? Devise seems pretty annoying with a separate front end + JWT stuff. I feel like there's probably something we could do with a provider (Auth0 maybe?), but I don't have direct experience with that.

Any opinions RE omniauth-google-oauth2 gem? It's a breeze to set up....

[rcamach7]

Frontend Tech Stack (revised)

• Language: Javascript (versatile, widely-used) or Typescript (type safety, robust)
• UI Library: React (component-based, efficient)
• Build Tool: Vite (modern, fast)
• State Management: Zustand (lightweight, simple API, no boilerplate) or Redux with RTK (predictable, excellent tooling)
• Styling Solution: TailwindCSS (utility-first, rapid development)
• Testing: Jest (supports React, part of Odin Curriculum)
• Authentication: JWT-based authentication (stateless, scalable)
• Other: ReactRouterDOM (popular client-side routing), ESLint (enforces code quality), Prettier (consistent code formatting), EditorConfig (unified editor settings)
• Worth Considering: Git Commit Linting (standardized commit messages, improved collaboration)

Backend Tech Stack

• Language: Ruby (dynamic, object-oriented)
• Framework: Ruby On Rails (powerful, MVC pattern)
• Authentication: JWT-based authentication (stateless, scalable, widely supported)
  • Authorization: Pundit (flexible, easy to use)
• Database: PostgreSQL (structured, scalable)
• Testing: RSpec (mature, widely used)

[mmxz-mmxz]

Also just want to bring up react-query again - we should probably consider this if we are doing CSR

[rcamach7]

Updated. I added Zustand as state management, and TailWindCss as the styling solution, per feedback. I also added authorization libraries for the backend. @mmxz-mmxz, are you suggesting react-query as an alternative to Zustand, or a data fetching tool? I have heard a lot about it but I haven't used.

@crespire brought up a great point on leaning on technologies that are most familiar to most Odin members. @Lofty-Brambles
Typescript will fall outside of that and will add a big learning curve to the project, which is why I believe Javascript is the right language for this. On the commit linting, it would allow us to force commit messages to follow a certain format, that we can add on the contributing guidelines. For example, we can force commit messages to start with "feat: ", "doc: ", etc. It's something optional that can keep commit messages clean.

[Lofty-Brambles]

As far as conventional commits go, yes, that would. That would also allow us to generate neater changelogs as well as better bug tracking and versioning of the project. Which's why conventional commits was a requested pattern and updated in the CONTRIBUTING.md. Furthermore, Typescript was an almost unanimously agreed upon conclusion from over on discord as well as other discussions, including the second comment on this discussion and the number of upvotes on the other comments over at the other styles post

[JaeGif]

Also just want to bring up react-query again - we should probably consider this if we are doing CSR

I’m a big fan of React Query. Small skill floor high skill ceiling compared to Redux, but most importantly, it’s just easy to use.

[RyanMcEntire]

@mmxz-mmxz In looking over the history of the project, you seem to have a concept for how the storybook components can be organized. It looks great. If you're interested in taking ownership of this section to plan how you see fit, I'd love to get going and make some progress on this part of the project.

It seems to me like we just need to pick a structure, and to break things down into groups of tasks that can be completed by individuals. Would you be able to take that on? The figma wireframe is complete, so it just needs to be broken down into actionable items.

[justEstif]

If vite is the build tool we are using, vitest is also worth considering.

Jest represents a duplication of complexity. If your app is powered by Vite, having two different pipelines to configure and maintain is not justifiable. With Vitest you get to define the configuration for your dev, build and test environments as a single pipeline, sharing the same plugins and the same vite.config.js.

• Vitest offers compatibility with most of the Jest API and ecosystem libraries
• faster run for your unit tests and a jump in DX thanks to the default watch mode using Vite instant Hot Module Reload (HMR)

I understand we are trying to stick with TOP content, but vitest being jest compatible means we avoid a lot of the jest setup while getting the DX boost and ease of setup.

[crespire]

I personally think that as long as webpack is in the curriculum, that's what the project should stick with, and I am not on the vite train.

It's like arguing over whether we should use import maps or sprockets or propshaft on the rails side. What does create-react-app spit out without any flags? I feel that's what we should use. I don't understand the move to vite, and I feel that vite is not an appropriate build tool for this project.

[edit]
It was pointed out that the react revamp is moving to vite. While I still think webpack is more appropriate for the project, this is not a blocker for me.

[rcamach7]

Here's a poll, to see if we can get close to a tech stack decision

https://qkld8z3tn.supersurvey.com

[rcamach7]

Frontend Tech Stack (Revised)

• Language: Typescript (type safety, robust) | 77% in favor
• UI Library: React (component-based, efficient)
• Build Tool: Vite (modern, fast) | 40% in favor
• State Management: Zustand (lightweight, simple API, no boilerplate) | 80% in favor
• Styling Solution: TailwindCSS (utility-first, rapid development)
  • Component Library: DaisyUI (uses tailwind, rapid development)
• Testing: Vitest (native to vite, fast) | 59% in favor
  • Development & Testing: Storybook (view components in isolation, easy documentation)
• Authentication: JWT-based authentication (stateless, scalable)
• Additional Technologies (only including those selected by > 50% of respondents):
  • ReactRouterDOM (popular client-side routing) | 52% in favor
  • ESLint (enforces code quality) | 100% in favor
  • Prettier (consistent code formatting) | 100% in favor
  • React Query (efficient data fetching) | 80.95% in favor
  • Git Commit Linting (standardized commit messages, improved collaboration) | 71.43% in favor

Backend Tech Stack

• Language: Ruby (dynamic, object-oriented)
• Framework: Ruby On Rails (powerful, MVC pattern)
• Authentication: JWT-based authentication (stateless, scalable, widely supported)
  • Authorization: Pundit (flexible, easy to use)
• Database: PostgreSQL (structured, scalable)
• Testing: RSpec (mature, widely used)

This is based on the results of the Poll Survey. The poll was open for 24 hours and received 22 responses. If there aren't percentages on a technology listed, then it had previously been decided by previous discussions to use those technologies.