IdeaSift

Python teams duplicate models across API layers

Python developers often maintain separate classes for the same data across Pydantic, Strawberry GraphQL, ORM, and client-facing API layers. Changes then need to be copied by hand, making drift and migration behavior hard to manage; class-factory approaches can also run into typing errors. The strongest evidence is for Pydantic–Strawberry duplication, while other reports point to the same broader synchronization burden.

For python API developers. Mentioned from Sep 2022 to Mar 2026 on GitHub and Hacker News.

7 different people described this problem in 3 separate discussions.

Week of 2026-07-13: 0Week of 2026-07-20: 0Week of 2026-07-27: 0Week of 2026-08-03: 0Week of 2026-08-10: 0Week of 2026-08-17: 0Week of 2026-08-24: 0Week of 2026-08-31: 0Week of 2026-09-07: 0Week of 2026-09-14: 0Week of 2026-09-21: 0Week of 2026-09-28: 0
0 mentions in the last 12 weeks
Indie fit
4.0/10
Pain
6.0/10
Frequency
7.5/10
Willingness to pay
0.0/10
Momentum
5.0/10
Who pays
Professionals
Competition
Medium
Build difficulty
Medium

What people said

Quoted word for word. Follow a link to read the whole discussion.

  1. Currently we support Pydantic via an, albeit experimental, integration, but the API is a cumbersome, as we need to create two classes, one for Pydantic and one for the Strawberry type
    patrick91 on GitHub (strawberry-graphql/strawberry)Sep 2022+78 upvotesAsked for a tool
  2. This is doubly annoying because we also have to define input types for a lot of these which end up duplicating a lot of the same information
    ppease on GitHub (strawberry-graphql/strawberry)Feb 2023Asked for a toolHas a workaround
Build brief

See what to build and who will buy it

  • 1 product idea with the smallest useful version and pricing
  • 4 places to find your first customers
  • 7 more quotes from people who have this problem
  • Current workarounds, existing solutions and risks