Forem: Alexey Ryabov

Real-world open-source projects built with Next.js 14 and App Router

Alexey Ryabov — Fri, 28 Jun 2024 12:57:54 +0000

Discover how others build real-world Next.js applications by examining their codebase.

Learning from others' codebases can help you grow as a developer, gain inspiration for organizing your codebase, develop a certain feature, manage CI/CD, and much more. You can learn both best practices and some practices to avoid in real-world scenarios. You can find new technologies that might better solve certain cases.

In this article, you will find a selection of open-source projects built using Next.js and App Router.

Unkey

GitHub · Website

Unkey is an open-source API management platform for scaling APIs. Unkey provides API key management and standalone rate limiting.

The repository is a monorepo managed via Turborepo. It contains several apps:

www - marketing website, landing page, blog, etc.
dashboard - main application
docs - documentation website

Stack: Turborepo, Tailwind, tRPC, Planetscale, Drizzle ORM, Clerk, React Hook Form, Zod, Resend, Stripe, Mintlify

Cal.com

GitHub · Website

An open-source Calendly alternative. A scheduling solution that gives you a full-control of your events and data.

They are still in the process of migrating to App Router, which is a good example of how a large-scale app can be migrated to App Router incrementally.

The repository is a monorepo managed via Turborepo. The main app is located in apps/web. There, you can find that it has both app and pages folder. And many routes from pages are available in app/future folder.

Stack: Turborepo, Tailwind, tRPC, Prisma, Kysely Auth.js, React Hook Form, Zod, Zustand, Tanstack Query, Stripe

Documenso

GitHub · Website

An open-source DocuSign alternative. A service for signing documents digitally.

The repository is a monorepo managed via Turborepo. It contains several Next.js apps:

marketing - marketing website, landing page, blog, etc.
web - main application

Stack: Turborepo, Tailwind, tRPC, Prisma, Kysely Auth.js, React Hook Form, Zod, Resend, Stripe

TypeHero

GitHub · Website

TypeHero is a platform for enhancing your TypeScript skills via interactive code challenges.

The repository is a monorepo managed via Turborepo. It contains several Next.js apps:

web - main application
admin - admin panel for the main application

Stack: Turborepo, Tailwind, Prisma, Auth.js, React Hook Form, Zod, Zustand, Tanstack Query, Resend

Dify

GitHub · Website

Dify is an open-source LLM app development platform. Dify's interface combines AI workflow, RAG pipeline, agent capabilities, model management, observability features and more.

Stack: Tailwind, React Hook Form, Zod, Zustand, SWR

Dub

GitHub · Website

Dub.co is an open-source URL shortening service and a link management platform. An open-source alternative to Bitly.

The repository is a monorepo managed via Turborepo. The main app is located in apps/web.

Stack: Turborepo, Tailwind, Planetscale, Prisma, Auth.js, Zod, SWR, Upstash, Tinybird, Stripe, Mintlify

Noodle

GitHub · Website

Noodle is a platform for managing everything to do with students education like note-taking, calendar, task management, grade calculator, flashcards and more.

It's an indie project and still not released yet. But it's a good example of an app built using modern technologies.

Stack: Bun, Tailwind, tRPC, Drizzle ORM, Clerk React Hook Form, Zod, Tanstack Query, Resend

Midday

GitHub · Website

An all-in-one tool for freelancers, contractors, consultants, and solo entrepreneurs to manage their finances, track projects, store files, and send invoices.

The repository is a monorepo managed via Turborepo. It contains several apps:

website - marketing website, landing page, blog, etc.
dashboard - main application, dashboard
docs - documentation website

Stack: Bun, Turborepo, Tailwind, Supabase, Upstash, React Hook Form, Zod, Zustand, Resend, Mintlify

Morphic

GitHub · Website

An AI-powered search engine with a generative UI.

Stack: Bun, Tailwind, Vercel AI SDK, OpenAI, Tavily AI, Serper, Jina AI, Upstash

Supabase

GitHub · Website

Supabase is an open source Firebase alternative.

Supabase doesn't use fully App Router but their new apps uses it. The repository is a monorepo managed via Turborepo. It contains several Next.js apps:

database-new - some new app by Supabase. It uses App Router.
www - marketing website, landing page, blog, etc. It doesn't use App Router yet.
studio - main application. It doesn't use App Router yet.
docs - documentation website. It doesn't use App Router yet. There is PR for migrating it to App Router - link.

Stack: Turborepo, Tailwind, OpenAI, React Hook Form, Zod, Tanstack Query, Stripe

OpenStatus

GitHub · Website

OpenStatus is an open-source synthetic and frontend performance monitoring service.

The repository is a monorepo managed via Turborepo. It contains several apps:

web - main application, landing page
docs - documentation website

Stack: Turborepo, Tailwind, tRPC, Upstash, Tinybird, Turso, Drizzle ORM, Auth.js, React Hook Form, Zod, Stripe, Resend, Mintlify

Skateshop

GitHub · Website

An open source e-commerce skateshop built with modern approaches and technologies.

It's not a real-world application but a good example of how to develop modern Next.js application.

Stack: Tailwind, Clerk, Upstash, OpenAI, Drizzle ORM, React Hook Form, Zod, Stripe, Resend

Feedbase

GitHub · Website

An open-source solution for collecting feedback and communicating updates.

The repository is a monorepo managed via Turborepo. It contains several apps:

web - main application, landing page
docs - documentation website

Stack: Turborepo, Tailwind, Supabase, Tinybird, React Hook Form, Zod, SWR, Resend, Mintlify

Plane

GitHub · Website

An open Source JIRA, Linear and Asana alternative. Plane helps you track your issues, epics, and product roadmaps.

The repository is a monorepo managed via Turborepo. It contains several Next.js apps:

admin - admin panel. It uses App Router.
web - main application. It doesn't App Router yet.
space - some application. It uses App Router.

Stack: Turborepo, Tailwind, React Hook Form, SWR, MobX

egghead.io

GitHub · Website

egghead a learning platform for front-end developers.

They are still in the process of migrating to App Router, which is a good example of how a large-scale app can be migrated to App Router incrementally.

Stack: Tailwind, tRPC, Prisma, Sanity, Formik, Zod, SWR, Tanstack Query, Upstash, Stripe

Conclusion

In this article, we explored several open-source projects built with Next.js 14 and App Router. These open-source projects serve as excellent learning resources, offering practical examples of how to leverage Next.js 14 and App Router to build robust, scalable applications. Whether you are looking to enhance your skills, find inspiration, or discover new tools, delving into these codebases will undoubtedly contribute to your growth as a developer.

Want to find more real-world projects? You can find more projects built with different technologies in my collection on GitHub.

Which open-source Next.js projects inspire you the most? Please, share your thoughts and experiences in the comments below.

How we estimate tasks in Story Points

Alexey Ryabov — Mon, 18 Dec 2023 09:56:57 +0000

Originally published here by Alexey Ryabov

Estimating story points may be a term you've come across in software development, as it is a common method used by teams to estimate the effort required to complete tasks. Unfortunately, without a deeper understanding of how or why it works, this method can be misused by teams and can even lead to unintended consequences and valuable time wasted.

This article will break down the fundamentals of what story points are and provide a step-by-step guide on how to use them to estimate tasks in software development teams.

Here's what we'll cover:

What are story points?
How to estimate in story points?
Why use story points?
Examples of using story points

At the end, you will find additional resources that can help you deepen your understanding of story points more.

What are story points?

Story points are an abstract unit of measurement to estimate the overall effort. Story points are a flexible and elegant method as they can take into account different factors based on your team's needs such as time, complexity, amount of work, risks and uncertainties, etc.

The tasks are estimated in story points relative to each other. That's why it's important to have some baseline tasks that you have estimated together with your team and have discussed that estimation in detail. This will serve as a benchmark for everyone to estimate the other tasks.

Story points are usually assigned using a scale such as the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, etc.). It's not a requirement to use this particular scale, you can use any scale that works for you. The advantage of the Fibonacci sequence is that it's a non-linear sequence that brings the following properties:

Represents well the idea that estimating a task becomes less precise as the task becomes larger.
Illustrates well the idea of relative sizing. Using a linear scale (e.g., 1, 2, 3, 4, 5) might give the false impression that each story point is the same amount more complex as the one before. The Fibonacci sequence avoids this pitfall by emphasizing that the relationship between sizes is approximate and non-linear. The ratio between values is more important than the values itself.

How to estimate in story points?

1. Define factors of story points

Before using story points, you need to define what a story point represents. You need to think about which factors are the most important for your team and describe them in detail.

The factors can vary between teams and projects.

In this guide, we will be using the following factors:

⌚ Time

Even though Time isn't usually listed as a factor in other guides, I believe that it's quite an important one for tasks that are clear (usually small tasks). Instead of trying to give a precise amount of time to implement a task, it's better to use an approximate amount which improves the accuracy of estimations and makes it easier to estimate. If it's too hard to predict, we give our estimate based on other factors. If other factors differ a lot from the time, then it can mean that you need to revisit your estimation.

Questions

How long does it take to complete the task approximately?

Options

0 - 2 hours
3 - 8 hours
9 - 16 hours
17 - 26 hours
27 - 40 hours
Unknown

🧠 Complexity

Complexity takes into account such things as a need for special knowledge, clarity of implementation, amount of edge cases, etc.

Questions

How hard is it to complete this task?
Do you need special knowledge to complete this task?
Is the solution clear or does it require some time to come up with a solution?

Options

Lowest
Low
Medium
High
Highest

🛠️ Amount of work

Amount of work assesses the sheer volume of work required to complete a task. This factor is quite related to Time but answers different questions. It's often the case when it's hard to estimate time but it's clear that you need to write a lot of code or you need to do some research before implementing a task.

Questions

Does it require writing a lot of code?
How much work needs to be done?
How much do you need to research?

Options

Lowest
Low
Medium
High
Highest

💣 Risk and uncertainty

Risk and uncertainty take into account things you can't know until starting a task. For example, you can't envision what issues you will stumble across during an upgrade of some library to a major version even when it has clear release notes.

Questions

How much is known about a task?
Is the task clear?
Is there something that's hard to predict?

Options

None
Low
Medium
High
Highest

In the Examples section, we will use those factors, commenting on a decision for each of them.

2. Determine your story point sequence

Your team needs to have a limited set of possible story points to make the estimation process more accurate and easier. It's not that important the actual values of story points. It can be numbers or even letters (e.g. S, M, L, see T-shirt sizing). But the values should be relative to each other and easy to understand.

Some popular choices are:

Fibonacci sequence (1, 2, 3, 5, 8, 13, 21)
T-shirt sizing (XS, S, M, L, XL)

It's usually a good idea to have a small set of story points (~5 options) because as an estimate becomes bigger it becomes less accurate. When your estimate is big for a task, it's a good sign that you need to break the task down into smaller tasks and estimate them separately.

In this guide, we will be using the Fibonacci sequence (1, 2, 3, 5, 8).

3. Create a story point matrix

A story point matrix helps your team to estimate tasks by accumulating all the factors. It makes estimations more consistent, helps the team to be on the same page when it comes to estimations and to argue the estimation.

4. Explain the concept to the team

Once you set the definition of a story point, determined a sequence, and created a story point matrix, now it's time to explain it to the team and show how to use it. It's important that each team member understands the concept.

5. Prepare baseline tasks for future estimates

You need to select some tasks that will act as a reference/baseline for future estimates and estimate them in detail together with a team using the matrix. It will simplify the estimation process a lot in the future and will make story points and the matrix much clearer.

The more you use story points, the more accurate estimates become so feel free to change baseline tasks from time to time.

Ideally, you need to have at least one baseline task for each story point value you have.

6. Set up a poker planning session

Poker planning helps to organize the estimation process. The idea of poker planning is that each participant estimates a task in story points privately and the result isn't shown until the voting is over. If the story points are the same, move on to the next task. If the story points differ much, it's time to discuss it together and clarify why participants chose a certain amount of story points.

There are a lot of tools for this. In our team, we use Slack for communication and it has a good extension "Poker Planner for Slack". It has all the configurations we need, it's easy to use, and makes it possible to make the session asynchronous.

7. Execute your sprint and measure its velocity

The beautiful side of estimation is that it allows us to measure a team's velocity. The velocity is the measure of a team's capacity to complete work during a sprint. Story points improve accuracy by having a limited amount of values and taking into account multiple factors. Knowing the team's velocity helps to see potential issues, discuss them with the team, and set realistic goals for the next sprints.

To calculate the velocity, you just need to calculate the total amount of completed story points when a sprint ends. This number is the velocity of your team for the sprint.

After completing several sprints, it's a good idea to measure an average velocity which will help you to understand how many story points you can plan for the next sprints.

Why use story points?

Now, when we know what story points are and how to use them, we can summarize the benefits of story points. Understanding these benefits will shed light on why teams often choose story points over other methods for estimation and planning.

More Accurate Estimations. Story points help us to estimate tasks more accurately compared to other simple measurements such as time because it takes into account multiple measurements, which often impact the estimations, such as complexity, amount of work, risks and uncertainties. Besides accuracy, it makes it easier to estimate because all the factors are approximate values and a team doesn't need to give precise estimations for each factor.
Reduced Pressure on Teams. Since story points aren't tied to time only and it's an abstract unit, it reduces pressure on teams which leads to more productive work.
Improved Team Collaboration. Story points define an exact process for estimating tasks. It involves the whole team into the estimation process and gives a common language for estimating which improves communication. Techniques such as "Poker planning" make the estimation process more efficient and productive.
Statistics. Story points help the team to analyze their performance by calculating different metrics such as velocity. Having statistics helps us to spot performance issues in advance, discuss it with a team, and plan the next sprints more accurately based on the statistics.

Examples

To better understand story points, let's estimate some tasks together using the matrix from this guide.

Task #1. Use pluralization rules for text

Description

We need to update all instances in the UI where we use a noun with a dynamic number to use a function that automatically applies the appropriate pluralization rule. For example, "1 word", "2 words", etc.

Additional context

We're going to use a library which we've used on other projects before. The codebase is of medium size and it's not hard to search in it.

Estimation

Time - 0-2 hours. Knowing the existing code base isn't very big, we're pretty sure that this task won't take more than 2 hours.
Complexity - Lowest. There is nothing complex to implement. We don't need to implement pluralization from scratch since we're going to use a library for that.
Amount of work - Low. It requires us to go through the codebase and find places where we need to update text.
Risk and uncertainty - Low. Since we don't know the exact places where we need to update text, there is a small risk of underestimating and having more places than we initially expected.
Points - 1

Task #2. Add virtualization to feed

Description

We have a feed of users' posts with infinite scroll. We need to implement virtualization in the list to improve its performance when the list becomes large.

Additional context

We're going to use some library for virtualization but we don't know which one yet. The list has items with dynamic height. The code for the feed is readable and written quite well.

Estimation

Time - 3-8 hours. We don't need to implement the virtualization logic from scratch since we're going to use some library for that. We previously had experience of applying virtualization in previous projects, so we know the general idea and know approximately how much time it can take.
Complexity - Medium. Virtualization is not a straightforward concept. To successfully apply it, we need to understand how it works. We have a dynamic height for a list item and an infinite scroll, which complicates the usage of virtualization.
Amount of work - Low. Since we had experience previously using some libraries for virtualization, we know that, in most cases, it doesn't require a lot of changes in the codebase. The code for the feed is written well, and it's easy to change and understand.
Risk and uncertainty - Medium. We don't know exactly what library we're going to use. There are some risks of something not working as before because it changes drastically the way the feed is rendered.
Points - 2. Here we have an uncertain situation because the factors we chose don't map to the matrix fully. From the matrix, it should be either 2 or 3. We ended up choosing 2 because everyone was sure that it wouldn't take more than 8 hours, and it was a decisive factor.

Task #3. Implement login page

Description

In the scope of this task, we need to add a new page /sign-in which contains a simple form with email and password fields and a submit button. We need to handle errors from API. We also need to establish architecture for protected/unprotected routes and make the login page available only for unauthenticated users.

Additional context

We're going to use some library for managing forms. We have all basic components like input, button, etc. in UI kit we use.

Estimation

Time - 9-16 hours. Based on previous experience and taking into account that we're going to use a lot of existing solutions, we think that it won't take more than 16 hours.
Complexity - Low. It contains pretty common functionality. UI doesn't have anything complex and most of the components are already ready. All the complex form management/validation will handle some library. Amount of work - Medium. We need to do several things, like choosing a library for form management, communicating with API, handling errors from API, implementing an architecture for protected/unprotected routes.
Risk and uncertainty - Low. It's clear how it should work. We know how to communicate with API. We have experience working with forms, so even though we don't know which library we're going to use, we don't expect a lot of risks from it.
Points - 3

Task #4. Implement chart on dashboard

Description

We need to implement a chart on a dashboard which shows some statistics. It's a bar chart with a tooltip. The design for the chart is custom.

Additional context

We're going to use some library for building charts but we don't know which one yet. We don't have any experience building charts. We need to implement it to look the same as on the design so we need a library where we can customize the appearance of charts as we need. We need to think about the loading state, empty state. We need to communicate with API.

Estimation

Time - Unknown. It's hard to estimate how much time it needs since we don't have prior experience in implementing charts.
Complexity - High. Data visualization isn't an easy concept and requires special knowledge to successfully build custom charts.
Amount of work - High. We need to find a library which covers all our requirements. We need to learn the found library and learn data visualization in general.
Risk and uncertainty - High. Since we never did it before, there are a lot of uncertainties and risks. We don't know which library we're going to use, we don't know how hard it's to use that library and which issues it has, we don't know how hard it's to learn data visualization.
Points - 8. Even though it might not take much time in the end, we still chose 8 because there are a lot of uncertainties.

Additional resources

If you want to understand better story points then I highly recommend to read these articles: