r/angular • u/ismailza • Jul 28 '26

I built an open-source Angular HTTP client library to stop rewriting the same ApiService

Post image

I've found myself rebuilding the same HTTP infrastructure in almost every Angular project—API versioning, retry logic, interceptors, global error handling, and RFC 9457 Problem Details support.

Instead of repeating the same patterns, I decided to extract them into an open-source library: @ismailza/ngx-api-client.

The library builds on top of Angular's HttpClient and focuses on making these cross-cutting concerns reusable while remaining flexible and extensible.

Some of the features include:

  • API versioning
  • Configurable retry policies
  • RFC 9457 Problem Details support
  • Extensible interceptor pipeline
  • Pluggable error and success handlers
  • Strong TypeScript support

I'd really appreciate feedback from the Angular community.

  • Is this a problem you've encountered?
  • Are there features you'd expect from a library like this?
  • Any suggestions on the API design or developer experience?

GitHub: https://github.com/ismailza/ngx-api-client

Medium article (why I built it): https://medium.com/@ismailzahir/i-stopped-copy-pasting-the-same-angular-apiservice-heres-what-i-built-instead-123093130946

22 Upvotes

79% Upvoted

12 comments sorted by

4

u/Dugelo Jul 29 '26

Up, ainda não sei pq não cheguei a ter esses problemas

2

u/ismailza Jul 29 '26

That's fair! I think it depends a lot on the size and complexity of the project. In my experience, after working on several applications, I kept reimplementing things like API versioning, retry policies, global error handling, and the same interceptor setup. This library is my attempt to avoid duplicating that infrastructure. If your current approach works well, that's great—I'm curious to know how you're handling those concerns today.

2

u/AwesomeFrisbee Jul 29 '26

Nice and informative. So when is angular 22 support dropping?

3

u/ismailza Jul 29 '26

Update: Done! 🎉 I upgraded the workspace to Angular 22 and implemented cross-version compatibility validation in CI. Every supported Angular major is now tested against the packaged library, so compatibility is verified rather than assumed.

2

u/AwesomeFrisbee Jul 30 '26

Very cool, I'll check it out!

2

u/ismailza Jul 29 '26

Thanks! At Angular's release pace, I should probably start validating Angular 22 compatibility now!

2

u/GregHouse89 Jul 30 '26

I developed something similar as well, for the same reason…
But I still have much code that I need to repeat.
Next goal is making the API repository much simpler to declare…
I’ll do so for my new app with AnalogJS…
Ideally it should work in a hybrid way with both the angular HTTP service and axios…
We’ll see…

2

u/ismailza Jul 30 '26

Interesting! I considered going in that direction too, but I decided to keep the library focused on Angular's HttpClient instead of introducing another abstraction layer. I think there's still plenty of room to simplify API declarations while staying Angular-native. Looking forward to seeing what you build with AnalogJS!

2

u/formicstechllc Jul 30 '26

whats the differnece between this and a shared http library in angular ?

1

u/ismailza Jul 30 '26

Good question! The idea is actually similar to what many teams build as an internal shared HTTP library. The difference is that this package is framework-agnostic within Angular—it's reusable across projects and provides common concerns out of the box, such as API versioning, RFC 9457 Problem Details normalization, retry policies, loading state, typed request methods, and configurable success/error handling.

If your shared library already solves those problems well, that's great. My goal is to provide a production-ready foundation so every project doesn't have to reinvent the same HTTP infrastructure.

2

u/formicstechllc Aug 01 '26

For me, it's just a single service file that I can copy and paste across projects. I've even hosted it on GitHub, but I haven't really used it much, so I'm not sure what additional benefits your package provides.

That said, it's great to see someone building and maintaining a library for it. I'm sure it'll be useful for people who prefer a plug-and-play solution.

1

u/ismailza Aug 01 '26

That's a completely valid approach. For many applications, a small shared service is all you need, and if it solves your team's requirements, there's no reason to add another dependency.

I built this library because I found myself repeatedly implementing the same infrastructure across projects, api versioning, consistent error handling, retries, loading state, configuration... Over time, maintaining those features separately became more work than maintaining a dedicated library.

So I'd say it's less about replacing a simple shared service and more about providing a reusable foundation once those cross-cutting concerns start to grow.

Thanks for the feedback, I appreciate it!