sayemimran/resell-hub-client

1. Overall shape

Resell Hub is a Next.js App Router application that combines the storefront, account areas, and dashboard experiences in one codebase. The repo is organized around route segments in src/app, with reusable UI and domain logic in src/components and shared auth/payment helpers in src/lib.

2. Primary runtime boundary

The visible backend surface is Next.js route handlers under src/app/api, not a separate server app in this tree. The README references Express and MongoDB, but in this repository snapshot the concrete API entry points are the Next route handlers, plus server/client helper modules that encapsulate authentication and payment calls.

3. Authentication subsystem

Auth is centered on Better Auth. The catch-all handler at src/app/api/auth/[...all]/route.js serves the auth endpoints, while src/lib/auth.js, src/lib/auth-client.js, src/lib/clientAuthFetch.js, and src/lib/server/serverAuthFetch.js split auth concerns between browser and server contexts. The login/register pages and forms live under src/app/auth/* and src/components/auths/*.

4. Marketplace storefront

Public commerce flows are split across home, product discovery, category browsing, cart, checkout, and order success routes. The landing page uses home components such as hero, featured products, stats, categories, and trust/social-proof sections. Product listing/detail pages live under src/app/products and src/app/products/[id], with reusable product cards, review sections, and add-to-cart controls in src/components/products.

5. Cart and checkout flow

Cart state is presented in src/app/cart using CartContents and related UI. Checkout is handled by src/app/checkout and src/components/cart/CheckoutForm.jsx, which likely posts to the src/app/api/checkout_sessions/route.js endpoint. That route is the payment boundary that creates Stripe checkout sessions; the success page at src/app/order-success handles the post-payment landing state.

6. Role-based dashboard boundary

The dashboard is segmented by role under src/app/dashboard: buyer, seller, and admin each have their own route subtree and page set. src/app/dashboard/layout.jsx and shared dashboard components provide the shell, navigation, and responsive sidebars, while each role has its own views and data widgets. This is an important architectural boundary: users only see the subset of commerce data relevant to their role.

7. Buyer workspace

The buyer area focuses on post-purchase and personal commerce management: orders, payments, and wishlist. Components like RecentPayments, WishlistPreview, OrdersTable, and buyer dashboard composites suggest that buyer pages are mostly read-oriented, showing order history and account activity rather than product management.

8. Seller workspace

Seller routes cover product creation, listing management, order handling, and seller analytics. The seller component set includes AddProductForm, MyProducts, ManageOrder, SellerOrderCard, and AnalyticsCharts, indicating a workflow where sellers can create/edit inventory, monitor fulfillment, and inspect performance metrics from within their dashboard boundary.

9. Admin workspace

Admin pages are dedicated to platform oversight: analytics, orders, products, and users. Client components such as AdminAnalyticsClient, AdminOrdersClient, UserTable, CategoryPieChart, and AdminProductCard point to a management console that aggregates system-wide data and supports moderation or operational review.

10. Profile and account management

Profile editing is separated into its own route subtree under src/app/profile and src/app/profile/edit/[id]. Supporting components include profile info, avatar, edit form, and password change form, which suggests account maintenance is treated as a distinct domain from marketplace browsing and purchasing.

11. Shared UI and layout system

The app uses a component-driven design system with reusable navigation, footer, dashboard shell, and content cards. src/app/layout.js and src/app/globals.css define the global app shell and styling, while feature components are grouped by domain so the same product, auth, and dashboard primitives can be reused across multiple routes.

12. Data and service integrations

The repo explicitly integrates Stripe for payments and Better Auth for sessions; MongoDB is the intended persistence layer per the README. Client/server fetch helpers suggest the app distinguishes between browser-initiated requests and server-side authenticated requests, which matters for diagramming trust boundaries and data flow between UI, auth, API routes, and external services.