A Redditor asked about the easiest way to fetch an API in Next.js with TypeScript types, highlighting the challenge of external REST APIs returning responses as any type, lacking type safety [27↑]. They seek advice on handling and typing these API responses properly.

One user suggested using tools like quicktype.io to generate types from a sample API response [14↑]. Another user pointed out that TypeScript cannot inherently know the API's return type and suggested using "as MyType" to cast the response to the expected type [16↑]. They also mentioned Zod as a schema validation library to assert the object type at runtime, catching unexpected API responses.

In a comment, the original poster included example of fetching data, awaiting response and converting to json [5↑]. Some one replied in short, just saying Fetch() [10↑].

Another user stated that type safety can't be guaranteed unless the protocol can guarantee it and recommended defining the expected structure and validating it during runtime [28↑].

A Redditor has experienced a significant increase in compile time after upgrading to Next.js 15, with startup times jumping from 5-10 seconds to 30-40 seconds [17↑]. However, after the initial startup, the application's speed seems unaffected.

In the comments, it was asked if turbo is enabled [4↑]. The original poster confirmed turbo is enabled [1↑]. It was suggested to review the build output log [1↑], but the original poster can't share it because of confidentiality reasons [1↑].

Ultimately, a suggestion was made to debug the TypeScript compilation times and compare the flame graphs between the old and new versions to identify any bottlenecks [5↑].

A Redditor is experiencing slow page navigation in their Next.js 14.02 app, both locally and in a Docker container, despite converting images to .webp format [9↑].

One user suggested using Suspense for expensive components [11↑], while another recommended ensuring the Docker container runs the Next.js app in production mode [11↑]. This might solve the problem when the experience is the same as local [2↑].

Another Redditor advised using suspense or pagination for large data fetches, noting that the prefetch attribute of the Link component only works in production [4↑]. They also suggested prefetching data on the server and checking the backend for slowness.

Finally, they suggested upgrading to Next.js 15 to use Turbopack, which will improve the development experience.

A Redditor inquired about the best way to use WordPress with Next.js for headless projects [3↑]. They noted that while REST API is acceptable, it lacks good dev ergonomics, and GraphQL can be overkill. They suggested a Firebase-like JS SDK that securely connects to WP with ready-made components to speed up UI integration. They also wondered if a shift to Payload/Strapi is already occurring.

One user suggested Faust.js and wpGraphQL [6↑]. Another user expressed concerns about Faust, mentioning that its future is uncertain since the company seems to be potentially pivoting away from it for HWP toolkit [3↑]. This user added that HWP toolkit provides examples of how to do it yourself, so there is nothing for them to maintain.

Another Redditor argued that there are better CMSs available, such as Contentful, Sanity, and Strapi, questioning why anyone would stick with WP in 2025 [5↑]. A Reddit user commented that REST is fine for basic use, but authentication and filtering can quickly become complicated [2↑]. They added that a clean SDK with prebuilt UI components would make it more dev-friendly and might prevent people from moving to Strapi or Payload too quickly.