Most software projects have one thing in common: an email sender package. From verification emails to regular updates, it’s something we encounter almost everywhere. Our developers often find themselves building slick and seamless email flows, again and again, for every project.
But there was a catch. They were doing it all themselves! This repetitiveness went against our commitment to efficiency. It needed a solution.
The team pondered using third-party packages (more on that later), but ultimately decided to go for the scenic route: building our own NuGet package for a truly seamless mail sender.
Why did we do it, and how does it work? Keep reading to find out!
The problem: Repetitive tasks
Our developers have been coding to send emails for years. Everyone has their own version – each more efficient than others. Yet, this process was causing some issues.
- Every developer codes mail sending differently leading to inconsistency.
- Developers were spending precious time on something that should have been reusable.
- More manual coding meant more chances for inefficiencies and bugs.
Take verification emails, for instance, a staple in almost every project. They used to look completely different across projects and this inconsistency could have become a long-term headache. Luckily, our devs were not about to let that happen.
The solution: Mail Sender
One of our talented developers came up with the solution – a .NET NuGet package designed to handle sending emails that are customizable for various use cases. He named it Mail Sender.
It addressed all our problems with the following benefits.
- Easy to integrate – just download and use.
- Reusable – eliminates redundant code.
- Standardized – saves time, reduces errors.
- Accessible – available to developers in and outside the organization.
This package changed many of our developers’ workflows for the better. Not only were they able to optimize their time better, they could see tremendous possibilities for optimization in the future. It inspired them to take more initiatives and drive change.
What other adventures will it inspire? We hope to share with you soon.
Now, over to the how of things…
Behind the scenes: The developer’s workflow
Once the problem was identified, the developer of this package looked around. Every developer in the team had at least one story about his mail sender coding. Different projects used different gateways for access and each codebase looked different.
It was time to build a centralized codebase. It was challenging, for sure. But what’s life without a little thrill?
The package was coded using C# and designed to work with any SMTP gateway or email-sending tool. Its features include:
- Email sending using SMTP
- CC, BCC and attachments support
- HTML email body support
- Secure connections support (SSL/TLS)
After the package was built, it was tested by implementing into the existing projects. The package now works smoothly with accessibility for developers everywhere.
Third-party packages vs. Mail Sender
Third-Party Packages | Mail Sender |
Often heavyweight and packed with features you may never use. | Lightweight by design, built only with what’s essential. |
Limited control over functionality and updates. | Full control and flexibility to adapt as needed. |
Built for generic use cases, not always aligned with developer realities. | Tailored to real developer needs, solving the exact problems we faced. |
These factors along with our love for a meaningful challenge drove us to build the custom package over using third-party ones. But you don’t have to build another package, of course.
If you want to streamline coding email senders for your projects, just download and use Mail Sender any time.
Using Mail Sender in your projects
Mail Sender is available for public use with dependencies on MailKit. For detailed instructions and the code snippet, visit nuget.org/packages/AsthaIT.MailSender.
Mail Sender may be a small package, but it’s already making a big difference. For a team that eats, breathes and sleeps ‘efficiency’, reinventing the wheel every time was not an option.
We’ve seen how it sharpens our workflows, and we can’t wait to see what it helps you build. Here’s to smoother codebases and bolder ideas. Cheers!
