#Next.js app router

1 messages · Page 1 of 1 (latest)

orchid wigeon
#

Using next.js 14.2 and App Router, I want to follow best practices and recommendations from Next.js on my production ecommerce site. I suggest the following architectural flow which I will inform new developers to utilize. What do you think about this?
UI Component (SearchComponent) -> Orchestrator (SearchOrchestrator) -> API Route (SearchRoute) -> Services (Commerce/SearchSDKService or Commerce/SearchHTTPService) -> Service returns to API Route, API route returns HTTP response to Orchestrator -> Orchestrator uses the SearchModel for the field mapping -> Orchestrator returns the modelled API response and constructed object (e.g. a product with relevant fields) to UI component.

Please also see the attached diagram.

image.png
craggy heraldBOT
#

Hi @orchid wigeon. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:

#

I'm sorry, but I can't provide feedback on your architectural flow or the attached diagram as they are not included in the provided knowledge sources. However, I can share some best practices and recommendations for building your application with Next.js and the App Router.

  1. Use Layouts: Layouts allow you to share UI across pages and enable partial rendering on navigation. This can be particularly useful for elements like headers, footers, or sidebars that are common across multiple pages. Learn more (https://nextjs.org/docs/app/building-your-application/routing/layouts-and-templates#layouts)

  2. Use the <Link> Component: The <Link> component allows for client-side navigation and prefetching, improving the performance of your application. Learn more (https://nextjs.org/docs/app/building-your-application/routing/linking-and-navigating#link-component)

  3. Handle Errors Gracefully: Create custom error pages to handle catch-all errors and 404 errors in production. This can improve the user experience when something goes wrong. Learn more (https://nextjs.org/docs/app/building-your-application/routing/error-handling)

  4. Follow Composition Patterns: Check the placement of your "use client" boundaries to avoid unnecessarily increasing your client-side JavaScript bundle. Learn more (https://nextjs.org/docs/app/building-your-application/rendering/composition-patterns)

  5. Migrate Incrementally: If you're migrating from the pages directory to the app directory, do so incrementally to reduce complexity. The app directory is designed to work simultaneously with the pages directory, allowing for page-by-page migration. Learn more (https://nextjs.org/docs/app/building-your-application/upgrading/app-router-migration#migrating-from-pages-to-app)

#
  1. Use Server Components: By default, components inside app are React Server Components. This is a performance optimization that allows you to easily adopt them. Learn more (https://nextjs.org/docs/app/building-your-application/rendering/server-components)

Remember, these are general recommendations and may need to be adapted to fit the specific needs of your application. For more detailed information, you can refer to the Next.js documentation (https://nextjs.org/docs).

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@orchid wigeon kapa.ai is still learning and improving, please let us know how it did by reacting below

orchid wigeon
#

@craggy herald Based on this text then, what do you think? Compare it to your documentation and suggested guidelines - is it following best practices? Are there any issues with it?
Using next.js 14.2 and App Router, I want to follow best practices and recommendations from Next.js on my production ecommerce site. I suggest the following architectural flow which I will inform new developers to utilize. What do you think about this?
UI Component (SearchComponent) -> Orchestrator (SearchOrchestrator) -> API Route (SearchRoute) -> Services (Commerce/SearchSDKService or Commerce/SearchHTTPService) -> Service returns to API Route, API route returns HTTP response to Orchestrator -> Orchestrator uses the SearchModel for the field mapping -> Orchestrator returns the modelled API response and constructed object (e.g. a product with relevant fields) to UI component.

craggy heraldBOT
#

Let me check the knowledge base for you. One moment! :books:

#

Based on the provided knowledge sources, your architectural flow seems to align with some of the best practices recommended by Next.js. Here's how it compares:

  1. UI Component (SearchComponent): This aligns with the recommendation to use React components for building your UI. If you're using the App Router, these would be React Server Components by default. Learn more (https://nextjs.org/docs/app/building-your-application/rendering/server-components)

  2. Orchestrator (SearchOrchestrator): While the term "Orchestrator" is not specifically mentioned in the provided sources, this could be seen as a way to manage data fetching and state management, which is a common pattern in React applications.

  3. API Route (SearchRoute): This aligns with the recommendation to use API Routes for accessing backend resources. Learn more (https://nextjs.org/docs/pages/building-your-application/routing/api-routes)

  4. Services (Commerce/SearchSDKService or Commerce/SearchHTTPService): This is a common pattern for abstracting away the details of data fetching, and it's a good practice to separate these concerns from your components.

  5. Service returns to API Route, API route returns HTTP response to Orchestrator: This is a standard flow for handling responses from services and aligns with the concept of using API Routes.

  6. Orchestrator uses the SearchModel for the field mapping: Using models to map fields can be a good practice to ensure consistency in your data structures.

  7. Orchestrator returns the modelled API response and constructed object (e.g. a product with relevant fields) to UI component: This is a common pattern in React applications, where data is fetched and then passed to components as props.

#

However, it's important to note that these are general observations based on the provided information. The specific implementation details and how well they adhere to best practices would depend on the actual code. For more detailed guidelines, you can refer to the Next.js documentation (https://nextjs.org/docs).

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@orchid wigeon kapa.ai is still learning and improving, please let us know how it did by reacting below

orchid wigeon
#

Am I missing a Middleware between point 2 and point 3? @craggy herald

craggy heraldBOT
#

Let me check the knowledge base for you. One moment! :books:

#

Based on the provided knowledge sources, incorporating Middleware into your flow could indeed be beneficial. Middleware in Next.js allows you to run code on the server before a request is completed. This can be particularly useful for tasks such as authentication, server-side redirects, path rewriting, bot detection, logging and analytics, and feature flagging.

In your architectural flow, Middleware could potentially be placed between the Orchestrator (SearchOrchestrator) and the API Route (SearchRoute). This would allow you to handle these tasks before the request reaches the API Route. However, it's important to note that Middleware should be lightweight and respond quickly to avoid causing delays in page load.

Here's how your updated flow might look:

UI Component (SearchComponent) -> Orchestrator (SearchOrchestrator) -> Middleware -> API Route (SearchRoute) -> Services (Commerce/SearchSDKService or Commerce/SearchHTTPService) -> Service returns to API Route, API route returns HTTP response to Orchestrator -> Orchestrator uses the SearchModel for the field mapping -> Orchestrator returns the modelled API response and constructed object (e.g. a product with relevant fields) to UI component.

For more information on how to use Middleware in Next.js, you can refer to the Next.js documentation (https://nextjs.org/docs/pages/building-your-application/routing/middleware).

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: