Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

First class support for popular instrumentation technologies #4007

Closed
tl-jarvis-prestidge opened this issue Feb 5, 2020 · 3 comments
Closed
Labels
needs triage This issue has not been looked into type: enhancement 🐺

Comments

@tl-jarvis-prestidge
Copy link

Feature Request

Nest covers integration with so many interesting frameworks and libraries and is encouraging microservices architectures, but completely lacks guidance and integrations with core technologies useful in helping observability. Things like Prometheus metrics, and (name your vendor) open tracing. Which really matters when taking your project to production.

Is your feature request related to a problem? Please describe.

Things like metrics, tracing, logging, health checks etc. are all core concepts in cloud native applications, but the tracing and metrics side of things feels like it's been neglected in nestjs. There's no clear way to add these to our applications and realistically they should be togglable and auto instrumented similar to other frameworks trying to do the same thing as nest. i.e. moleculer seem to be on top of this.

Describe the solution you'd like

Bring in popular prometheus / jaeger / zipkin integrations to give the community some guidance and confidence in the ability to instrument a nestjs application with industry-standard metrics and tracing tech.

Teachability, Documentation, Adoption, Migration Strategy

What is the motivation / use case for changing the behavior?

I'd like to integrate Prometheus and Jaeger in my cluster with some nestjs applications and although there's are numerous npm packages to do so, I feel as though this should be a concern at least partial solved with a reciepe for nest 🙏

@tl-jarvis-prestidge tl-jarvis-prestidge added needs triage This issue has not been looked into type: enhancement 🐺 labels Feb 5, 2020
@BrunnerLivio
Copy link
Member

BrunnerLivio commented Feb 5, 2020

Thanks for your extensive issue - though we track it here #967.
For now, you will have to rely on community packages, or use e.g. swagger-stats.

@tl-jarvis-prestidge
Copy link
Author

tl-jarvis-prestidge commented Feb 5, 2020

I know you're trying to purge duplicates and keep your issues groomed, but the scope of this issue is different.

This feature request is asking for metrics and open tracing to be added to official nest modules. It's a call to action to consider prioritizing telemetry and observability as a whole.

The linked issue is specifically regarding a community Prometheus library, it's stale and without any action in over a year.

@BrunnerLivio please consider re-opening the issue, I think this is important for nest going forward. I'm here for constructive reasons. As per Nests motto, how can you deliver your promise to "build scalable server-side applications" without the above?

@kamilmysliwiec
Copy link
Member

kamilmysliwiec commented Feb 6, 2020

@tl-jarvis-prestidge Please note that Nest is compatible with every existing Node.js library and creating official wrappers for all of them is simply impossible for us to handle. For instance, you can easily use Nest with sequelize, knex, typegoose, even though the "official modules" for these packages don't exist. If you look at the official repositories such as @nestjs/elasticsearch or @nestjs/jwt, you will see that they are composed of a few files and could be built in minutes by everyone without even having a good knowledge & understanding of NestJS.

I think this is important for nest going forward. I'm here for constructive reasons. As per Nests motto, how can you deliver your promise to "build scalable server-side applications" without the above?

Delivering a framework that helps developers and teams to create highly testable, scalable, loosely coupled, and easily maintainable applications doesn't mean "create a wrapper for every single, popular Node.js library that has been built over the last 9 years". If you look into our documentation, you'll see this:

However, while plenty of superb libraries, helpers, and tools exist for Node (and server-side JavaScript), none of them effectively solve the main problem of - Architecture.

Our goal from the very early beginning was to provide an opinionated, testable architecture which makes Node.js projects easier to maintain & scale. As long as devs learn how to leverage this architecture (and we show how beneficial it is with several "official" modules), they should be able to wrap and use anything with Nest.

PS.

The linked issue is specifically regarding a community Prometheus library, it's stale and without any action in over a year.

Modules that wrap the official packages don't really have to be updated unless breaking API change was introduced in the underlying library. Typically, wrappers are very thin and expose a simple interface to interact with other packages (which usually are maintained by larger organizations). I've personally used "nestjs-prom" library and it worked quite well.

@nestjs nestjs locked as resolved and limited conversation to collaborators Feb 6, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
needs triage This issue has not been looked into type: enhancement 🐺
Projects
None yet
Development

No branches or pull requests

3 participants