Two Apps or One: Navigating SSR and SPA for Your Product

Hello everyone! Today, I want to dive into a topic that many developers face when building products with different user types and varying requirements. As I embark on creating a product with two distinct types of users—Team Members and Users—I’m faced with a crucial architectural decision: Should I build two separate applications or consolidate everything into one?

Understanding User Roles

Before we delve into the technicalities, let’s clarify the roles of the two user types:

• Team Members: These users will always be logged in and primarily interact with the dashboard, where they will manage a variety of tasks. Their experience needs to be fast, responsive, and fluid since they will be using the dashboard frequently.

• Users: These individuals will visit public-facing pages, such as a list of posts, a roadmap, and a changelog. While they may log in, their main interaction is with public content. They are less likely to navigate extensively, and their devices might not be as powerful, meaning a smooth experience is crucial for them as well.

The Dilemma: SSR vs. SPA

When considering the architecture, I want to implement Server-Side Rendering (SSR) for the public-facing pages for optimal performance and SEO. On the other hand, for the dashboard, I want a Single Page Application (SPA) experience to facilitate a better user experience, especially since Team Members will be interacting with it extensively.

The dilemma boils down to whether I should:

1. Create Two Separate Applications: One for SSR (using a framework like Next.js) and another for the SPA experience (using React with TanStack Router).
2. Utilize Next.js for Both: Use Next.js for the entire app but leverage Next.js’s client-side capabilities for the dashboard while still benefiting from SSR for public pages.

Pros and Cons of Each Approach

Option 1: Two Separate Applications

Pros:

• Clear separation of concerns for different user experiences.
• Each app can be optimized for its specific use case.

Cons:

• Increased complexity in maintaining two codebases.
• Challenges in syncing components and features across apps, leading to potential duplication of effort.
• More effort required in deployment and CI/CD processes.

Option 2: Single Application with Next.js

Pros:

• Simplified maintenance with a single codebase.
• Easier to share components and libraries between user types.
• Streamlined development and deployment processes.

Cons:

• Potentially larger bundle sizes for users who may not need access to the dashboard.
• Need to ensure that the dashboard experience remains smooth and responsive even when using SSR.

Insights from the Community

In exploring this question, I received valuable feedback from fellow developers:

1. Simplicity is Key: One commenter advised against complicating the architecture unnecessarily. They suggested sticking to simple React without SSR, emphasizing that if a simpler solution exists, it’s often the best path forward.

2. Standardization: Another developer pointed out the importance of standardizing the tech stack unless there’s a compelling reason not to. This approach not only simplifies maintenance but also eases the training of new team members.

3. Flexible Architecture with TanStack: A third comment highlighted that it’s possible to create SSR with TanStack and SPAs with TanStack Router, allowing for shared code and components. This could provide a balanced solution that addresses both the SSR needs for public pages and the SPA experience for the dashboard.

Conclusion: Finding the Right Path

As a backend developer navigating the frontend waters, I understand the weight of this decision. While creating two applications might provide clear distinctions, the burden of maintaining two codebases could significantly increase development overhead. On the other hand, using Next.js for both the SSR public pages and the SPA dashboard could streamline my workflow and simplify maintenance.

Ultimately, the decision will depend on the specific needs of the product and the resources available. As I continue to explore potential solutions, I welcome thoughts and pointers from fellow developers who have faced similar challenges.

What are your experiences with SSR and SPA? How did you choose to architect your applications? Let’s share our insights and help each other build better products!