Background

Before we dive in, let me set the stage with a few key points about my background and approach:

• I'm not particularly strong in frontend development (I've worked on both mobile and web, but I wouldn't call it my forte)
• Backend development is more my speed, but I don't see much value in building a backend at the prototyping stage (the database is crucial, not so much the backend itself)
• I have a decent grasp of ML and AI concepts
• This approach is tailored for small-scale, B2C services that aren't aiming for massive scale right off the bat

Current Tech Stack

Here's the tech stack I'm currently using for rapid prototyping:

Next.js

• Leveraging the App Router
  • Route Handlers for specific external API needs (e.g., Auth0 Triggers)
  • Server Actions for most server-side processing, keeping it simple and fast
  • Each page.tsx in the App Router acts somewhat like a ViewModel in MVVM
  • Keep page.tsx as React Server Components (RSC)
  • Mix and match Client and Server Components within as needed
  • Use router.push to force state updates across the app
  • Utilize useState for data that changes frequently within a page
• Balancing Server Components, Server Actions, and a touch of Client-side ISR
  • ISR comes in handy for updating data without full page reloads

Pain point: Juggling 'use server' and 'use client' can get confusing. It's easy to lose track of where components are being generated.

Vercel

• One-stop-shop for deployments and databases
• Embracing the "Framework-defined" approach, letting Vercel handle as much as possible
  • Avoiding tools like CDK to reduce onboarding friction and maintain simplicity
• Using v0 for design help
  • Leveraging v0 for Presentational Components
  • Integrating with shadcn UI components for a cohesive design system
  • Tip: Let v0 handle modifications to /components for consistency

Integrations:

1. Auth0
   • Great for B2C with a generous free tier
   • Quick to implement with built-in authentication screens
   • Pain point: Debugging Triggers can be a nightmare due to limited logging
2. Neon (Serverless Postgres)
   • Chose Neon over alternatives like Supabase for better Vercel integration
   • Seamless env variable management through Vercel CLI
   • Pain point: Table management through Vercel's integration page can be cumbersome

Vercel Wishlist: Please make Blob Storage generally available soon!

Proposed Project Structure

Based on the article Next.js の基本原則から学ぶシステム設計, here's a suggested project structure:

app/
  page.tsx
  products/
    _components/     # components
      XxxXxx.ts     # Data fetching container component (server component) 
      action.ts      # Colocation for server actions
    page.tsx         # UI assembly using _components (server component)
components/          # Presentational components (client components)
  ui/                # shadcn UI components
  xxx-xxx.tsx        # v0 auto-generated components

This structure aims to separate concerns while maintaining a clear organization that aligns with Next.js App Router conventions and the principles of rapid prototyping.

Closing Thoughts

This approach allows for quick iterations without getting bogged down in excessive code or infrastructure management. By leveraging tools like Next.js, Vercel, and their integrations, we can focus on building and validating our ideas rapidly.

Remember, the goal here is to strike a balance – we're not going full no-code, but we're also not building everything from scratch. This middle ground allows for flexibility, speed, and the ability to scale when needed.

What are your thoughts on this approach? Have you found other tools or methods that work well for rapid prototyping in the JavaScript ecosystem?