Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Scaffold Web App #37

Open
jollyjerr opened this issue Jul 11, 2023 · 2 comments
Open

Scaffold Web App #37

jollyjerr opened this issue Jul 11, 2023 · 2 comments
Labels
priority: low not a biggie scope: large work split across many packages spike the goal of this issue is to create better issues

Comments

@jollyjerr
Copy link
Collaborator

jollyjerr commented Jul 11, 2023

This is more of a spike ticket but wanted to get some ideas going.

Not sure if this should be a priority for now at all. It could wait until we build out the project more for sure.

  1. Should the web app be public or private?
  2. Should we use next.js? What alternatives should we consider? Will the server need to support multiple clients in the future, like a mobile app?
  3. Can we use tailwindcss pleaaaaaseee?
  4. Font, colorscheme, landing page design(ish)
  5. buy domain name

Pros to next.js:

  • Vercel is amazing
  • pr preview deployments easily
  • low cost (free?) initially
  • nextauth is actually really good these days
  • react server components seem dope

Cons to next.js:

  • Vercel is your new god
  • Backend has to be in node
  • Eventually high costs
  • Serverless can add some complexities for sure
@jollyjerr jollyjerr added the effort: 3 heroic label Jul 11, 2023
@jollyjerr jollyjerr changed the title Scaffold Webapp Scaffold Web App Jul 11, 2023
@jollyjerr jollyjerr added priority: low not a biggie scope: large work split across many packages spike the goal of this issue is to create better issues and removed effort: 3 heroic labels Jul 11, 2023
@mpryor
Copy link
Collaborator

mpryor commented Jul 11, 2023

My thoughts:

  1. I think we should start with the web app private. We can always open source later
  2. Having limited experience with Next.js, I'm on board to use it. It seems to be a great developer experience. I do think it would be good to consider various client use-cases for the future - will we have a public API? What protocol/presentation layer will it use (HTTP/Rest, GraphQL, gRPC, etc)? Can we think of use-cases where it makes sense for people to build their own clients for our API, assuming we have a public one? (notree tui, etc)
  3. Yeah, let's do it! ✔️
  4. Probably need a separate issue for coming up with a design system - We could start by extracting a color palette from our logo and seeing how that looks on a web page.
  5. Thoughts on this one - Where do you prefer to purchase a domain from (GoDaddy, Vercel, Route53, etc)? Or does it depend ultimately where we host the infrastructure?

Some more thoughts on the Next.js conversation:

Vercel is your new god

This is the area I'd be concerned. Vercel is SO easy to get up and running on, but I don't have experience with actually doing any sort of DB integration on there. If we decided to migrate off Vercel onto another stack later, I don't think it would be hard to containerize a Next.js app, but the data integration layer might be costly to migrate

@jollyjerr
Copy link
Collaborator Author

Yo! I don't really care where we get the domain from, totally agnostic on that 😄 . I think it might be cool for us to just launch into a next app for now! I do get scared about needing a better backend eventually for supporting mobile apps or a public api - but perhaps we can cross that bridge when we get there? Whatever you feel good with I'm good with! I'll make a new issue for a design system!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority: low not a biggie scope: large work split across many packages spike the goal of this issue is to create better issues
Projects
None yet
Development

No branches or pull requests

2 participants