/api routes treated as static pages? compile failure
Answered
Citrus blackfly parasitoid posted this in #help-forum
Citrus blackfly parasitoidOP
I have a
Wait a minute-
- Why is it trying to open the database file anyway during build time specially on the
- I'm assuming it does so because it's treating
- I don't know if this is a bug yet. : )
const db = new Database("_path_does_not_exist_during_build_time") and my api routes utilise the db var. The problem is during build time @ the "Collected Page Data" & "Generating Static Pages" step where next throws the following, > Build error occurred
Collecting page data ...SqliteError: unable to open database file
Error: Failed to collect page data for /api/x/y/zWait a minute-
- Why is it trying to open the database file anyway during build time specially on the
/api route? - I'm assuming it does so because it's treating
/api as static pages. But why?? It makes no sense to call an api route during compile time. - I don't know if this is a bug yet. : )
Answered by Eric Burel
because Route Handlers are indeed statically rendered as a default on the GET endpoint
22 Replies
Could you share a minimal reproduction repository with us?
Is it a route handler?
is it in "app/api" or "pages/api" basically?
because Route Handlers are indeed statically rendered as a default on the GET endpoint
Answer
this is to allow people to do stuff like generating images rather than HTML pages
you need to add "export const dynamic = "force-dynamic"" in your file
and I suggest doing that to all route handlers you create
@Z4NR34L Could you share a minimal reproduction repository with us?
Citrus blackfly parasitoidOP
I wish I could! I'll try to reproduce it. I haven't been able to yet otherwise I would've diagnosed it further.
@Eric Burel is it in "app/api" or "pages/api" basically?
Citrus blackfly parasitoidOP
It's
app/api!@Eric Burel because Route Handlers are indeed statically rendered as a default on the GET endpoint
Citrus blackfly parasitoidOP
That's strange. If I may, why is it enforced by default? Shouldn't static (for I assume, it must be for improving cache) be an opt-in?
caching by default is best option, as it's safest for everyone - specially less experienced devs to prevent unexpected usages spikes and delivery troubles for bigger count of users when something has gone viral
also it's providing best performance experience to users - if you want to deliver live data, you have just to opt-out by any option available (for example by setting runtime to edge on route)
@Citrus blackfly parasitoid That's strange. If I may, why is it enforced by default? Shouldn't static (for I assume, it must be for improving cache) be an opt-in?
It's debatable honestly
The thing is that route handlers are not exactly to be thought as normal REST API endpoints like API routes where in "pages"
The thing is that route handlers are not exactly to be thought as normal REST API endpoints like API routes where in "pages"
"routes" are typically functions that generates non HTML content like images etc.
there are 2 competing use cases, using them as API endpoint, or using them to generate things
given that Server Actions can also cover the "API endpoint" use case
(by using them to fetch data interactively)
so if you take the whole picture I think that makes sense, it's just a bit unsettling because it's very new
@Z4NR34L caching by default is best option, as it's safest for everyone - specially less experienced devs to prevent unexpected usages spikes and delivery troubles for bigger count of users when something has gone viral
Citrus blackfly parasitoidOP
I agree although I believe next should warn instead of throwing an error that "xyz" (in my case the database connection) was absent during static page generation and maybe skip that
/api endpoint or something if it's un-computable.@Eric Burel It's debatable honestly
The thing is that route handlers are not exactly to be thought as normal REST API endpoints like API routes where in "pages"
Citrus blackfly parasitoidOP
I see! While "server actions" are relatively new. They're an opt-in feature. I believe everyone who uses next views the
/api directory for both app router and pages router as the place to put their api endpoints. If someone was using them to generate things, if on server; rsc they can simply call the function that generates their thing but if on client; they'd have to call the route via fetch(). I believe enforcing cache on /api routes by default isn't fair since now edge cases like these are impossible to overcome because now the issue translates to a limitation of framework itself.@Citrus blackfly parasitoid I agree although I believe next should warn instead of throwing an error that "xyz" (in my case the database connection) was absent during static page generation and maybe skip that `/api` endpoint or something if it's un-computable.
yes that's probably a good UX, maybe via a config param like "optinStaticRoutes" or alike, anyway when you know it it's easier to avoid this trap ^^
@Citrus blackfly parasitoid I see! While "server actions" are relatively new. They're an opt-in feature. I believe everyone who uses next views the `/api` directory for both app router and pages router as the place to put their api endpoints. If someone was using them to generate things, if on server; rsc they can simply call the function that generates their thing but if on client; they'd have to call the route via `fetch()`. I believe enforcing cache on `/api` routes by default isn't fair since now edge cases like these are impossible to overcome because now the issue translates to a limitation of framework itself.
yeah technically, you can think of RSC pages as generating HTML, and Route Handler GET endpoints as generating anything else, but they behave otherwise quite similarly