App Router

Odys leverages the Next.js App Router to structure its frontend, embracing modern React features like Server Components and a file-system-based routing paradigm. This architecture allows for efficient data fetching, improved performance, and a clear separation of concerns between server-rendered and client-interactive parts of the application.

Overview

The App Router organizes the application into a hierarchical structure where folders define routes and special files (page.tsx, layout.tsx, loading.tsx, etc.) define UI for those routes. Odys primarily uses page.tsx for route-specific content and layout.tsx for shared UI across segments. A key characteristic of Odys's App Router implementation is its heavy reliance on Server Components for initial data fetching and rendering, minimizing client-side JavaScript where possible. The application also employs route groups, such as (auth), to logically organize routes without affecting the URL path. Notably, Odys does not currently use Next.js middleware, opting instead to handle authentication and authorization checks directly within Server Components or API routes.

Server Components

Server Components are fundamental to how Odys fetches and renders data. These components execute exclusively on the server, allowing direct database access and secure handling of sensitive logic without exposing it to the client.

Consider the src/app/p/[slug]/page.tsx file, which renders a professional's public booking page. This entire page is a Server Component. It performs several data fetching operations directly:

• It queries the professionals table using Drizzle ORM (db.select().from(professionals).where(eq(professionals.slug, slug)).limit(1)) to retrieve the professional's details based on the slug parameter. This data is then used to populate the page's content, including the professional's name, profession, session details, and bio.
• The generateMetadata function, also a Server Component feature, fetches professional data to dynamically set the page's title, description, and Open Graph images, optimizing for SEO and social sharing.
• It interacts with Supabase (createClient(), supabase.auth.getUser()) to determine if the current visitor is logged in and, if so, whether they are the owner of the professional page (user?.id === prof.userId). This check influences the navigation links and the display of the FollowButton.
• If a logged-in user is not the owner, the page fetches their client data from the clients table (db.select().from(clients).where(eq(clients.userId, user.id)).limit(1)) to pre-fill the booking form, enhancing user experience.
• Related professionals are fetched from the professionals table based on the current professional's profession.
• Reviews for the professional are fetched by joining the reviews and clients tables (db.select().from(reviews).innerJoin(clients, eq(reviews.clientId, clients.id)).where(eq(reviews.professionalId, prof.id))) to display client names alongside their ratings and comments.

This approach centralizes data fetching and rendering on the server, reducing the amount of client-side JavaScript and improving initial page load performance. Client-side interactivity, such as the BookingWidget and FollowButton, is then added using Client Components, which are explicitly marked with the "use client" directive (though not shown in the provided page.tsx code, these are typically imported from separate files).

The root src/app/layout.tsx also functions as a Server Component, defining the global HTML structure, applying global CSS (globals.css), and integrating fonts (Plus_Jakarta_Sans, Montserrat). It also defines global metadata for the application, including default title, description, and Open Graph/Twitter card details. Additionally, it integrates global UI components such as Toaster for notifications and CookieBanner for consent management. For accessibility, a 'Skip to main content' link is included to assist keyboard and screen-reader users. It also includes third-party analytics and performance monitoring tools like Vercel Analytics and Speed Insights, and PostHog for product analytics, all rendered on the server. A small inline script is used with dangerouslySetInnerHTML to prevent a flash of unstyled content by applying the saved theme before the page renders.

Route Groups

Odys uses route groups to organize parts of the application without affecting the URL structure. The primary example is the (auth) route group, which would typically contain routes related to user authentication, such as login, registration, and password recovery. The specific layout file src/app/(auth)/layout.tsx is currently missing from the codebase. The existence of the (auth) folder indicates an intention to group these routes logically, allowing for a dedicated layout or specific server-side logic to be applied to all routes within this group, such as redirecting unauthenticated users or providing a consistent authentication UI.

Absence of Middleware

Odys does not implement Next.js middleware. Instead, authentication and authorization checks are handled directly within the Server Components themselves or within API routes. For instance, in src/app/p/[slug]/page.tsx, the supabase.auth.getUser() call directly checks the user's session to determine isOwner status. This design choice simplifies the request lifecycle by avoiding an additional layer of processing that middleware would introduce. It means that each Server Component or API route is responsible for its own access control, fetching user data as needed.

Design Decisions

The decision to heavily rely on Server Components for data fetching and rendering stems from a desire to maximize performance and simplify the data access layer. By fetching data directly from the database within page.tsx files, Odys avoids the need for a separate API layer for initial page loads, reducing network roundtrips and complexity. This also allows for direct, secure access to the Drizzle ORM and Supabase authentication utilities without exposing database credentials or sensitive logic to the client.

The use of route groups like (auth) is a structural choice aimed at improving code organization. It allows developers to group related routes and apply shared layouts or logic to them, even if a specific layout file for (auth) is not yet implemented. This promotes modularity and makes the project structure easier to navigate.

The absence of Next.js middleware reflects a preference for a more direct approach to authentication and authorization. Rather than intercepting all requests at the edge, Odys performs these checks contextually within the Server Components or API routes that require them. This can simplify debugging and ensure that security logic is tightly coupled with the resources it protects, though it requires careful implementation in each relevant component.

Potential Improvements

1. Optimize Database Queries for Related Professionals: In src/app/p/[slug]/page.tsx, the allRelated query fetches all professionals of a given profession from the professionals table. The filtering (filter(p => p.slug !== slug && p.id !== prof.id)) and slicing (slice(0, 4)) to get related professionals are performed in memory after fetching all results. This could be optimized by incorporating the filtering and limiting directly into the Drizzle ORM query, reducing the amount of data transferred from the database and processed on the server.
2. Implement (auth) Route Group Layout: The (auth) route group exists in the file structure, indicating an intention to group authentication-related routes. However, the src/app/(auth)/layout.tsx file is not found. Implementing this layout would provide a dedicated and consistent UI wrapper for all authentication pages (e.g., login, register), allowing for shared components, styling, or even pre-authentication checks specific to these routes, improving maintainability and user experience.
3. Centralize User Role/Ownership Logic: The isOwner check in src/app/p/[slug]/page.tsx is performed directly within the BookingPage component and then used for conditional rendering in multiple places. As the application grows, centralizing this logic into a reusable hook or a dedicated context provider could improve code readability, reduce duplication, and make it easier to manage user roles and permissions across different parts of the application.

References

• src/app/layout.tsx
• src/app/p/[slug]/page.tsx