Route extraction shouldnt load the whole app in dev server

[lennybakkalian]

I dont want to be that type of guy that just reopens a issue. But i only saw @alan-agius4 answers on that topic and i would kindly ask other angular engineers about their opinion and if its something that can be solved differently. Maybe without @alan-agius4 indirect implication that it would "only" be solveable with file based routing.

There are no docs on route extraction, but my understanding now is that all routes are computed in advance. I'm not deeper into angular code than the public_api, but I can't imagine that a full application load (full lifecycle or template execution) are necessary to figure this out. What does this have to do with route extraction?

proof of concept
In this example, it would only make sense for SSG if the REQUEST token is not available on the server. (but according to @alan-agius4 its "bad practice" to think that the REQUEST token is available on the server with disabled prerender) - Just think about that for a second.

Sorry if I'm a bit salty, but it took me a really long time to figure out that (imo this bug) is due to the angular dev server.

Related to:
#28995
#28727 (comment)
#29084 (my previous ticket)
Angular Discord - My thread
Angular Discord - Another thread
and probably many more

[alan-agius4]

In this case, the REQUEST token being null ensures alignment between ng build and ng serve.
To closer mimic the production environment, the application is bootstrapped twice. This approach prevents route extraction from polluting the application state during the rendering of the first route. During the build process, the application is bootstrapped, causing the root component (app.component.ts) to execute and extract routes. At this point, there is no actual request, as highlighted in our documentation: https://angular.dev/guide/hybrid-rendering#accessing-request-and-response-via-di

During route extraction, the application is bootstrapped to:

1. Retrieve the router configuration and perform validation checks.
2. Build the routing table to avoid redundant operations during the first request or in serverless/worker environments, where requests can be frequent.
3. Surface validation errors at build time instead of runtime, ensuring smoother execution.

Bootstrapping enables key operations to be performed ahead of time:

• Running getStaticParams in the injector context: This ensures dynamic parameters for routing are generated before runtime.
• Supporting dynamic routes: Routes can be built or modified at runtime, such as when pulling data from an API to construct paths dynamically.
• Enabling localization of routes: Routes can be adjusted based on user locales, supporting internationalization seamlessly.

By "bad practice," I meant that developers should avoid relying on the request being guaranteed in a server-side application during execution. Ensuring applications are future-proof and adaptable allows them to take advantage of upcoming features where a request might not always be available. This approach also provides flexibility to switch rendering modes in the future if needed.

/cc @dgp1130 for additional input.

[lennybakkalian]

Thank you very much for the detailed explanation.

Bootstrapping enables key operations to be performed ahead of time:

Running getStaticParams in the injector context: This ensures dynamic parameters for routing are generated before runtime.
Supporting dynamic routes: Routes can be built or modified at runtime, such as when pulling data from an API to construct paths dynamically.
Enabling localization of routes: Routes can be adjusted based on user locales, supporting internationalization seamlessly.

Aren't these all things for which we don't actually need a component lifecycle? I would have thought that if you create routes dynamically, you would do this via a provider and not via components.

As I said, I am not familiar with the angular internal code, but even for child routers it should somehow be possible to generate these routes AOT without doing a complete component lifecycle. I don't see any reason why components should create routes dynamically, do you? Or have internal things been built so that a refactor would be too big in relation to this bug?

[dgp1130]

@alan-agius4 is definitely the expert here, so I don't think I have too much more to add. Like he mentioned, route extraction is useful to do at build time even if you don't have any RenderMode.Prerender routes. The serverless point I think is particularly relevant. If we skipped build-time route extraction, serverless deployments need to repeat that work per-request in the worst case, which can be a significant performance regression for large apps in a use case where they likely want peak performance.

Regardless, it feels like you want to write a component which requires a Request object, but I don't think that's currently feasible to do. Angular components still need to support client-side rendering, even if they are only used in pages with SSR because it is always possible to client-side navigate after loading a separate route. So it's generally not safe to require a Request object exists. There's architectural benefits to minimizing this coupling like Alan mentioned, but also doing so would just break CSR anyways (and probably hydration too?).

I think the only time it could hypothetically be safe to require a Request is if you always render a component via @defer with hydrate never and also only have a single route which is always SSR'd. Those are not safe assumptions to make, nor is it a good idea to couple a specific component's implementation to a lack of other routes in your application. Angular components have an implicit requirement that they need to be renderable from scratch on the client. Requiring a Request object breaks that requirement and means certain actions which should work on any Angular component (ex. CSR) now don't work on this particular component.

[alan-agius4]

Just to add some more, currently when an application is bootstrapped using the bootstrapApplication method in main.server.ts, Angular also bootstraps the root component, which triggers its lifecycle hooks.

Code: https://github.com/angular/angular/blob/46f00f951842dd117653df6cca3bfd5ee5baa0f1/packages/core/src/platform/bootstrap.ts#L136

While this behavior shouldn’t be strictly necessary, it is how Angular currently initializes an application. I’ve been exploring a potential solution to prevent the root component from being invoked during this process. I have a change in mind to do in the framework that should address this issue, but I still need to verify that it doesn’t introduce any unintended side effects or break other functionality.

[lennybakkalian]

I have a (probably naive) question without knowing the internal code of angular:

When angular is called with bootstrapApplication, the AppComponent and the appConfig are passed.
All routes are defined as providers in the appConfig. Both static and dynamically generated (via http requests, which you used as an example). Can't the config from provideServerRoutesConfig be used to recognize which components are to be prerendered and only these have the lifecycle? If there is no SSG, it would be unnecessary to call guards, resolver, components and so on, wouldn't it?

I just don't know how to handle this case in my app/library, because requests are made for the first page load, which must return a correct value, otherwise errors will occur. If it's just an app, I could just make a guard that blocks this "ghost" request, but in my case it's a library and you can't do that.

If you are the expert on this topic, of course I respect your decision and you can close the ticket if you really think there is no way around it. I just think it's a bit sad because I really like angular and have liked all the decisions so far, except for this one :/

[alan-agius4]

hen angular is called with bootstrapApplication, the AppComponent and the appConfig are passed.
All routes are defined as providers in the appConfig. Both static and dynamically generated (via http requests, which you used as an example). Can't the config from provideServerRoutesConfig be used to recognize which components are to be prerendered and only these have the lifecycle? If there is no SSG, it would be unnecessary to call guards, resolver, components and so on, wouldn't it?

We don’t invoke the guards, or lifecycle hooks of all components, only those that are referenced in the AppComponent (root page). I am looking into a way to not do this.

I just don't know how to handle this case in my app/library, because requests are made for the first page load, which must return a correct value, otherwise errors will occur. If it's just an app, I could just make a guard that blocks this "ghost" request, but in my case it's a library and you can't do that.

I am not quite sure of your use-case, but especially in a library, I would say that it paramount not to assume the existing of a request, otherwise the library will not be compatible with other rendering modes including CSR or potentially you will end up using isPlatformServer and isPlatformBrowser quite a bit which isn’t ideal. There is actually a good article about this (written by @CaerusKaru): https://medium.com/@caerus.karu/isplatformbrowser-is-not-your-friend-5ee52b06da89

I am happy to provide more information, if you provide some more context on what you are trying to do in this library.

[lennybakkalian]

I am not quite sure of your use-case, but especially in a library, I would say that it paramount not to assume the existing of a request, otherwise the library will not be compatible with other rendering modes including CSR or potentially you will end up using isPlatformServer and isPlatformBrowser quite a bit which isn’t ideal.

My library actually works exactly like the http client (with hydration and csr). I would have the same problem with the http client.

Imagine an empty angular app where an auth guard http.get('/api/user/self') is used in the root path. If a cookie with the user token exists in the header, the current user is returned, otherwise a new one is created and returned. The problem is that no header (no REQUEST) is found in ssr context by this “ghost” bootstrapApplication and therefore a new user is created. I think this "ghost" call should not happen for routes that have RenderMode.Server

In prod it wouldn't be a problem, I understand that. But during development, a new user is created with every frontend change. This is just an example and I am aware that this behavior can be avoided with a dirty fix. if(isServer && !REQUEST){ return false } but i don't think it's such an elegant solution tbh

I strongly believe that the more people upgrade now and use ssr in the dev server, they will have this same issue.

[alan-agius4]

If a cookie with the user token exists in the header, the current user is returned, otherwise a new one is created and returned.

However, request.cookie is not available in CSR. How is this currently handled in CSR when users navigate between pages, and no server request is made or the cookie is absent?

The problem is that no header (no REQUEST) is found in ssr context by this “ghost” bootstrapApplication and therefore a new user is created

I'm not fully clear on the "create user" process. Are you creating a new user for every request that lacks a cookie? For instance, if I make 10,000 requests without a cookie, will 10,000 new users be created? This seems like a significant security risk unless your application is internal and not publicly accessible.

if(isServer && !REQUEST){ return false } but i don't think it's such an elegant solution tbh

I agree, relying on isBrowser or isServer checks isn't great. When handling different logic for server and client in general you want services to handle difference in logic, Ex:

// auth.service.ts
@Injectable()
export abstract class AuthService {
  abstract isAuthenticated(): Promise<boolean>;
  getUserId() { }
  createUser() { }
  // other common methods
}

// browser-auth.service.ts (Browser Implementation)
export class BrowserAuthService extends AuthService {
  isAuthenticated(): boolean {
    const token = document.cookie;
    return !!token; 
  }
}

// server-auth.service.ts (Server Implementation)
export class ServerAuthService extends AuthService {
  private readonly request: Response | null = inject(REQUEST);

  isAuthenticated(): Observable<boolean> {
    const token = this.request?.headers?.get('cookie');
    return !!token; 
  }
}

// auth.guard.ts
export const authGuard: CanActivateFn = (route, state) => {
  const authService = inject(AuthService);
  const router = inject(Router);
  const isAuthenticated = authService.isAuthenticated();
};

[lennybakkalian]

This seems like a significant security risk unless your application is internal and not publicly accessible.

Something like Anonymous Sign-Ins like supabase does it are totally fine and are no security risk.

TLDR:
Anonymous sign-ins can be used to build:
E-commerce applications, such as shopping carts before check-out
Full-feature demos without collecting personal information
Temporary or throw-away accounts

But it's not about the actual implementation. I just wanted to make a simple example to demonstrate what side effects a “ghost” bootstrap would have.

Because of this unexpected behavior, there will be more and similar issues/questions like this:
https://stackoverflow.com/questions/79158723/angular-cookie-not-available-in-the-first-execution-of-app-initializer-function
Someone there said: "So you can ignore these bugs and carry on development, because when you deploy with SSR, it should work fine." And where he is right, I find such a proposed solution for a framework that should work in a comprehensible way somewhat painful.

[alan-agius4]

Thank you for the additional information. I am currently focusing on resolving the issue, rather than running the AppComponent.

To clarify and correctness, while the issue described in https://stackoverflow.com/questions/79158723/angular-cookie-not-available-in-the-first-execution-of-app-initializer-function may seem similar, it is actually a very different problem. The root cause there is that the APIs used are tightly coupled with Express, which makes them non-portable and incompatible with the dev-server.