Conversation
…ng to work on it later on.
…ng to work on it later on.
…nd included custom-logger-plugin.js demonstration.
• examples/custom-logger-plugin.js • fastify.js
• Rebased logManagementSystem branch onto main branch • Began writing documentation in /docs/Reference/Server.md
- Added customRequestLog factory option to fastify.js - Added TypeScript type definition to fastify.d.ts - Updated documentation in docs/Reference/Server.md - Added example plugin in examples/custom-logger-plugin.js
Eomm
left a comment
There was a problem hiding this comment.
Quick share of my opinion on the logger topic:
instead of adding an option for each line in the framework (such as:
customRequestLog, requestIdLogLabel, disableRequestLogging and probably other that I'm missing), I would just create a small layer that that user can totally replace without getting mad with all the combinations of these parameters.
It could by my christmas time funny task
Hi @Eomm, thank you for the suggestion! I agree, I think this would be a much cleaner approach. Before I start, I'd like to make sure I understand correctly, are you suggesting I include a replaceable logging layer that would handle all framework logging (request logs, error logs, etc.) that users could swap out entirely? I'll work on this and keep you updated. And yes, maybe it can be an early Christmas gift! Thank you again. |
Yes: right now the user can already change the logger (by implementing a well defined API), but we have some "system logs" that users wants to customize. If we want to deliver this feature as non-breaking I think we should proceed like this:
In this way, we will never have another feature request regarding the default log lines because they will be totally replaceable |
|
Sounds good, thank you for this suggestion, I think this approach will make the codebase more efficient and less error prone. If I have any questions I will be sure to let you know. Thank you. |
Prerequisites
[✓] run npm run test && npm run benchmark --if-present
[✓] tests and/or benchmarks are included
[✓] documentation is changed or added
[✓] commit message and code follows the Developer's Certification of Origin and the Code of conduct
Proposal
Implement a customizable log management system through an encapsulated plugin
Description
Hello, I've been working on customizing the log management system which originally was derived from #4463.
As previously specified in #4463, we currently have a log management system set in place which only displays a default message, "incoming request", as shown below:
The purpose of this PR is to allow the user to customize the log management system so they can include criteria and data that is compatible with their particular project.
For this particular feature, I have implemented a plugin approach rather than hard-coding the logger through route.js.
The objective of the plugin approach is to produce an object or plugin that is encapsulated by a childLogger object. This plugin will possess and inherit all the log management system properties it needs to create a customizable log management system. In addition, it can be reused and shared through several different Fastify projects.
Advantages
• Object is reusable
• Contains settings and properties directly adopted through the childLogger object. As a result, it has the capability to perform more functionalities and logic.
• The whole entire Log Management system is now encapsulated through an object. Therefore it makes it easier to perform functionalities. It’s also much more organized and maintainable than the previous approaches.
• Scalable and adaptable.
Modifications
fastify.jsAdded customRequestLog factory option:
Updated onBadUrl and buildAsyncConstraintCallback error paths:
fastify.d.ts:Added TypeScript type definition:
examples/custom-logger-plugin.jsAdded example plugin demonstrating hook-based logging:
docs/Reference/Server.mdIncluded documentation for customRequestLog option
Please tell me what you think. Thank you