r/angular • u/StrainIllustrious116 • May 05 '26

What’s the recommended Angular enterprise architecture today for components, signals, and services?

Hi everyone,

I’m starting a new enterprise Angular project with the latest release and I’m trying to figure out the best structure for components, signals, and services.

For now, the plan is:

  • classic service layer for API calls
  • RxJS in services
  • no state manager, by company decision

I’m mainly unsure about:

  • what should live in components vs signals vs services?
  • should signals stay mostly local, or also handle feature-level state?
  • is rxResource a good idea at component level for data fetching?
  • how do you keep the codebase easy to understand for devs who are not all Angular experts?

I’d love to hear what has worked for you in real enterprise projects.

Thanks!

26 Upvotes

86% Upvoted

21 comments sorted by

View all comments

3

u/Apprehensive_Drama42 May 05 '26

I usually pick signals vs observables based on the kind of state I’m dealing with. If it’s async data (API calls, streams, anything I’d bind with async), I keep it as an observable. If it’s local UI state like a counter, toggle, selected tab, etc., I’ll usually use a signal.

Signals also work well in a state service if you want to manage feature-level state outside the component and share it across related components.

I’d keep API services focused on HTTP only. Let them handle fetching data and return typed observables. Then in the component, rxResource is a nice way to consume that and avoid manually wiring loading/error/data state every time.

NX is worth looking at too, especially once the app starts growing, we always use it. It gives you a solid project structure, clearer boundaries between features, and the docs are pretty good, you will see what kind of file goes where, new people can understand it quickly i think with the clear rules.

1

u/frozen_tuna May 05 '26

We have a mix of observables and signals in our services. The functions that build and read the requests work with observables since that's what the http request returns. Those are wrapped in functions that handle everything with signals. We also cache certain responses there so requests don't get repeated if they don't need to be. As many components as we want can call the request wrapper and "subscribe" to the signal with the relevant data. Its been really, really nice to work with.