Avoid Turning Open Source Projects into Proprietary Solutions
In this article, I want to highlight the potential problems that may arise when you take an open source project and modify it to suit your needs. This is what I experienced.
The Keycloak email verification mechanism
Last year, I was working on a microservice integrated with Keycloak for authentication. During the daily, one of the business analysts mentioned that Keycloak would send a verification email for as many times as you click it. There is no buffer mechanism in that implementation, and you could spam your email account very easily. The analysts in collaboration with the client, asked that after 3 email verification deliveries to be able to wait for 5 minutes before having the possibility to send another email.
I started looking for a solution. At that time, Keycloak had no implementation for the requested buffering system. I opened an issue on the Keycloak Github repository and waited 1–2 days for someone to pick it up.
Since nothing happened and I was asked to get it done, I forked the repository and started working on it myself. I made the modification, tested it, tried to follow the guidelines of Keycloak community and finally, created a Merge Request. From the source code, I generated a custom Docker image for internal/customer usage and since then, it has been running great.
If you are facing a similar issue, I wrote about this activity in the following article.
Custom headers with OpenAPI Maven Generator
Lately, we faced at work a rather simple problem at first. Using OpenAPI (also known as Swagger) we added a header placeholder for each controller, so that it was easier for testing. However, when we generated the controller clients using openapi-maven-generator-plugin , these headers were added as method parameters.
Clearly, this was a behavior we did not want, because firstly, we manage the headers centrally through a filter for each request and secondly, the code was being polluted. Clean code is a must!
I did not know much about OpenAPI Maven Plugin and its configurations. Where is the best place to look for? The documentation. I browsed everywhere and I was not able to find anything (little did I know!). I asked a question on StackOverflow about the issue and no one was answering. Time was passing and I decided to go with the source code modification.
I forked the OpenAPI Generator repository in Github and created my custom implementation in a matter of minutes.
https://github.com/lejdiprifti/openapi-generator
I picked the tag we were using in our daily work and build upon that. Finally, the plugin with version 6.6.1-SNAPSHOT was published in the company’s artifactory.
It worked! But at what cost?!
However, there was already a solution to do it. You needed simply to add <implicitHeaders> true </implicitHeaders> in your plugin configurations. This property skips implicit headers from being added as parameters in methods generated. Exactly what I was looking for.
Lessons learned
What I have learned from doing such modifications, is to try to avoid them at any cost.
Your project will inevitably create a dependency to this custom implementation. If you are delivering to a client, you will have to deliver also the custom implementation you did.
Additionally, you are bounded to a specific version of the dependency / plugin / project. If you later on decide to upgrade, you can’t do it because your implementation will get lost.
The following are the lessons learned:
- Always research and make sure that what you are looking for does not exist.
- Evaluate different solutions.
- Become a contributor to the open source project and contribute the solution to all.
That’s the beauty of open source projects. You can contribute easily.
Thank you for reading!
If you want to read more posts, checkout my blog https://lejdiprifti.com/blog/
