Introduction

In this post, I'll discuss the factors that influenced our decision to choose Next.js as the primary framework for our frontend ecosystem. Given the limitations of the legacy system, it was essential to select a framework that could address our specific needs and challenges.

Key Considerations

Before making a decision, we carefully considered the following factors:

• Performance: We needed a framework that could handle large-scale applications without sacrificing performance.
• Community support: A strong community ensures access to resources, libraries, and solutions.
• Modularity: We wanted a framework that allowed us to include necessary libraries on-demand.
• Hybrid approach: We sought a framework that supported both server-side rendering (SSR) and client-side rendering (CSR).
• Typesafety: We prioritized a framework that enforced strong typing to prevent errors and improve maintainability.
• API contracts: We needed a way to define clear API contracts between the frontend and backend.
• Testing: We wanted a framework that supported unit testing and other testing methodologies.
• Documentation: Comprehensive documentation is essential for knowledge sharing and onboarding new team members.

Why Next.js?

After careful evaluation, we decided to go with Next.js for the following reasons:

• SSR and CSR: Next.js provides a flexible environment for combining SSR and CSR, allowing us to optimize performance based on specific use cases.
• Built-in API server: The built-in API server simplifies the development process and provides a convenient way to mock data.
• Static site generation: Next.js generates pre-rendered static pages, improving initial load times and SEO.
• Scalability: The framework's modular architecture makes it easier to scale the application as needed.

TypeScript and Typesafety

To ensure strong typing and prevent errors, we enforced the use of TypeScript as our primary coding language. TypeScript provides static type checking during the build process, helping to identify potential issues early on.

API Management

We used Tanstack Query, Zod, and Zodios to manage API requests, responses, and validation. Additionally, we leveraged OpenAPI specifications to generate types for our APIs, ensuring consistency between the frontend and backend.

Unit Testing

While we initially considered Vitest, we ultimately chose Jest with React Testing Library (RTL) for unit testing. Although we didn't achieve 100% code coverage, we aimed for at least 80% to ensure adequate test coverage.

Documentation

To avoid the documentation challenges of the legacy system, we planned to create extensive documentation covering key implementations and processes.

Conclusion

By carefully considering our requirements and evaluating available options, we selected Next.js as the ideal framework for our frontend ecosystem. In the next post, I'll discuss the process of bootstrapping the application with a GitHub repository.