You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am facing a separate, but similar issue to #29005 @alan-agius4, in my case, the 30-sec timeout occurs because I am making api calls.
My setup is pretty standard:
2 angular 'client' apps (ssr with fastify)
one 'server' api (fastify)
The '/api' route on both clients are expected to point to the same api instance
In production, '/api' on both client apps are routed the api via nginx and docker configuration
In development, I serve both the api and client locally, and use ng serve's proxy config
This means I can avoid having to stream my api data through my client's container. This is especially a win for production environment.
Because of this setup, I do not need to have a separate 'api' route in my client application.
BUT...
When angular tries to build my app, to extract the routes,
it makes request to the angular engine
in order to render the app, angular engine needs to make some api calls. Those api calls go to '/api'.
but there is no nginx config, or proxy config, so it passes the request to the client's fastify instance.
the client fastify instance does not have a handler for '/api' so it passes the request to the '*' route
'*' route is handled by.... angular engine
And so it loops and loops.
A. It was not immediately obvious that is a problem of recursion, and not a problem of route not able to render.
B. This is probably behaving as intended. But it forces developers to implement a fallback for api routes, or any other route that is expected on the same origin, just to build in peace. This was not needed before. We did not need to have runtime things available at build-time.
C. Yes, api route example was there in the initial generated server.ts. But it did not tell me "DO NOT DELETE THIS - YOU WILL NEED THIS LATER". Basically, maybe a more thorough documention is in order
D. Alternatively, would it not be great if we configure the build action to pick up proxy information, just like ng serve?
Following are the relevant files for the server setup
server.ts
import{createNodeRequestHandler,isMainModule}from'@angular/ssr/node';import{serveAngularSSR}from'@easworks/app-shell/utilities/angular-ssr';import{fastifyCors}from'@fastify/cors';import{fastify,FastifyInstance}from'fastify';import*aspathfrom'node:path';import{fileURLToPath}from'node:url';import{parseEnv}from'server-side/environment';import{useProblemDetailsGlobally}from'server-side/utils/fastify-problem-details';import{getLoggerOptions}from'server-side/utils/logging';import{printRoutes}from'server-side/utils/print-routes.plugin';constenvId=parseEnv.nodeEnv();asyncfunctioninitServer(){// const options = development ? {} : { http2: true };constoptions={};constserver=fastify({
...options,logger: getLoggerOptions(envId)});returnserver;}asyncfunctionconfigureServer(server: FastifyInstance){server.register(useProblemDetailsGlobally);server.register(printRoutes);server.register(serveAngularSSR,{directory: path.resolve(fileURLToPath(import.meta.url),'../..'),});awaitserver.register(fastifyCors,{origin: true});}constserver=awaitinitServer();awaitconfigureServer(server);asyncfunctioncloseServer(server: FastifyInstance){awaitserver.close();process.exit();}/** * Start the server if this module is the main entry point. * The server listens on the port defined by the `PORT` environment variable, or defaults to 4000. */if(isMainModule(import.meta.url)){consthost='0.0.0.0';constport=Number.parseInt(process.env['PORT']asstring);try{awaitserver.listen({ host, port });process.on('SIGTERM',()=>closeServer(server));process.on('SIGINT',()=>closeServer(server));}catch(e){server.log.fatal(e);closeServer(server);}}/** * The request handler used by the Angular CLI (dev-server and during build). */exportconstreqHandler=createNodeRequestHandler(async(req,res)=>{awaitserver.ready();server.server.emit('request',req,res);});
I am registering ngrx/store by calling provideStore()
And then registering ngrx/effects by calling provideEffects()
One of the effects is responsible for pulling in data required by almost everything, even menus. So that is triggered at the time of registration of the effect.
Command
build
Description
I am facing a separate, but similar issue to #29005
@alan-agius4, in my case, the 30-sec timeout occurs because I am making api calls.
My setup is pretty standard:
The '/api' route on both clients are expected to point to the same api instance
In production, '/api' on both client apps are routed the api via nginx and docker configuration
In development, I serve both the api and client locally, and use ng serve's proxy config
This means I can avoid having to stream my api data through my client's container. This is especially a win for production environment.
Because of this setup, I do not need to have a separate 'api' route in my client application.
BUT...
When angular tries to build my app, to extract the routes,
And so it loops and loops.
A. It was not immediately obvious that is a problem of recursion, and not a problem of route not able to render.
B. This is probably behaving as intended. But it forces developers to implement a fallback for api routes, or any other route that is expected on the same origin, just to build in peace. This was not needed before. We did not need to have runtime things available at build-time.
C. Yes, api route example was there in the initial generated server.ts. But it did not tell me "DO NOT DELETE THIS - YOU WILL NEED THIS LATER". Basically, maybe a more thorough documention is in order
D. Alternatively, would it not be great if we configure the build action to pick up proxy information, just like
ng serve
?Following are the relevant files for the server setup
server.ts
serve-angular-ssr.ts
Describe the solution you'd like
No response
Describe alternatives you've considered
No response
The text was updated successfully, but these errors were encountered: