Hello Spring Boot developer;
I developed this tool to easily monitor incoming and outgoing API traffic. My goal was to enable faster debugging by making request headers and bodies clearly visible, and to provide built-in request statistics directly within the application—without the need for any external tools.
Key Features of SpyFcc:
- Easy Integration: Effortlessly integrates into your project.
- Built-in UI: Comes with an embedded user interface right out of the box.
- Flexible Storage Options: Choose to store your traffic logs either in a file or a database.
- Data Masking: Automatically masks sensitive data to keep your application secure.
- Customizable Logging: Gives you the flexibility to skip logging for specific controllers or methods you want to exclude.
Why Should You Use It?
If you are a backend developer, you can easily monitor both real-time and historical API traffic without needing any external tools. If you want to quickly identify the most frequently used or failing endpoints in your application, you can seamlessly add SpyFcc to your Spring Boot project!
For more details and instructions on how to use it, you can check out the links below:
GitHub Repository: https://github.com/spyfcc/springspy
Official Website: https://www.spyfcc.com
If you have any feedback or find any bugs, feel free to reach out to me at developer@spyfcc.com. I am actively continuing to develop and improve the project!
Top comments (4)
Nice, this is actually useful.
Only thing I’d watch:
Feels like something I’d use in dev/debugging for sure 👍
The parameters you need are traffic.spy.workingthread and traffic.spy.max-body-size. I hope you'll use it in production as well. Logging will run quietly in the background. The application is still very new. Please don't hesitate to let me know if you notice any missing features or areas that need improvement. User experience is very important to me.
Got it, that makes sense.
Having control over body size + worker threads definitely helps keep it manageable.
I’d still be a bit careful with full payload logging in high traffic scenarios, but this looks solid for controlled prod use where you need visibility.
One thing that could be really useful later is some kind of sampling or adaptive logging based on load.
Thank you for the valuable feedback. Currently, the logging works as follows: it uses a memory store (limited by the traffic.spy.memory-size parameter in the cache), and a file or DB store (supporting JDBC and Mongo; I plan to add Redis and Elasticsearch support in the future). I will implement the structure you suggested for high-traffic applications—such as logging only 500s or non-200 responses—and keep you updated. As you mentioned, focusing on request bodies while skipping response bodies makes a lot of sense. Your suggestions on adaptive logging and sampling were truly eye-opening; I will definitely be evaluating them for the project.