Treat the boundary as an architecture decision
RxJS is excellent for streams, cancellation, websockets, complex async composition, and events over time. Signals are excellent for current values, derived UI state, and component-level readability.
The mistake is choosing one tool for the whole app. The better decision is naming where each one owns behavior.
readonly query = signal("");
readonly users$ = this.api.users$;
readonly filtered = computed(() => filterUsers(this.users(), this.query()));Keep API flow explicit
API calls often need cancellation, retry, error mapping, and loading state. RxJS can coordinate that flow well. Signals can then expose the current UI state without making templates subscribe everywhere.
Try the idea
Review the state shape before the feature grows
If the feature has filters, pagination, selected rows, and API state, write down what is a stream, what is local, and what is derived.
Production notes for Angular apps
Angular features stay maintainable when state ownership is obvious. Before adding another shared service or utility, decide whether the behavior belongs to a component, a feature boundary, an API service, or a reusable UI primitive.
The best Angular code is boring to navigate: feature folders are predictable, templates stay readable, and async behavior has a clear home instead of being scattered through lifecycle hooks.
Conclusion
Signals make Angular state easier to read when RxJS keeps doing the stream work it was built for.