Hello! My name is Bazen, and I'm a software engineer who enjoys working on exciting projects and, of course, coffee. One of my favorite frameworks is .NET and the C# programming language. I want to share my journey from contributing to maintaining the .NET SDK for Memphis. Memphis is an open-source project, and in this article, I will start by explaining what Memphis is, my contribution journey, and, last but not least, the different ways others can contribute to Memphis and other open-source projects.
What is Memphis?
Memphis is a next-generation message broker. It is a simple, robust, and durable cloud-native message broker. It provides cost-effective, fast, and reliable development of modern queue-based systems. Memphis scales exceptionally well with large volumes of streamed and enriched data. It is designed with development experience in mind and requires significantly less development time for data-oriented developers and data engineers than other solutions. Memphis is transparent and provides visibility on the activities taking place, which is helpful when troubleshooting. Memphis is feature rich and contains several features not mentioned here. I recommend checking it out on GitHub and The official Memphis website to learn more about it.
My Contribution
I was working on a company project involving working with high-volume data. I was researching different event streaming platforms such as Kafka, RabbitMq, Amazon SQS, and more to find a suitable solution, and that is how I stumbled across Memphis. At first glance, I was impressed by the observability of the platform, which motivated me to set it up locally and try it out. I played around with the Go SDK and quite liked the platform, which inspired me to learn more about it on GitHub.
At the time, Memphis already had SDKs in multiple languages, such as Go, TypeScript, and Python. However, the Memphis .NET SDK was in an early stage. Recognizing the platform's potential, I took it upon myself to reach out to the Memphis team and asked how I could contribute to the .NET SDK. Not long after that, I received a response from Yaniv Ben Hemo, the Co-Founder and CEO at Memphis. He was very welcoming and pointed me to the issues I could work on.
I worked on one of the issues and made my first pull request to the Memphis .NET SDK, and I was pleased by the encouraging feedback from the Memphis community.
Since then, I have contributed actively to the .NET SDK of the Memphis project. In addition, I am an active participant in the community, helping to resolve issues, guiding new contributors, and ensuring that the .NET SDK for Memphis remains up-to-date and fully functional.
What I Learned
As a Software Engineer, contributing to open-source projects and building in public is very important, and it provides the opportunity to learn about a new subject in detail. For example, my understanding of message brokers and their technical complexity was limited before Memphis. Some interesting things I learned from Memphis are schema verse and dead letter station.
Schema verse is a schema store and schema management layer on top of the Memphis broker. It's a neat way to specify and enforce the data structure, and this is useful to validate input data and increase its quality. The schema can be defined from the Memphis UI and using code, and one schema can be applied to multiple stations. The supported formats are ProtoBuf, Avro, JSON, and GraphQL. You can learn more about schema verse at Memphis.
The other concept is the dead letter station(DLS), which is where faulty messages end up. A message can be considered faulty for many reasons, for example, if it doesn’t satisfy the enforced schema, if a consumer fails to process it properly, and so on. In these scenarios, instead of dropping these messages, Memphis stores them in the dead letter station(DLS) along with a log that explains why the message is in DLS. This is helpful when troubleshooting and increases the application’s resilience. You can learn more about DLS at Memphis.
Memphis has many features that make a developer's life easier and an exciting project to learn from and contribute to.
How To Contribute?
A good starting point for anyone who would like to contribute is to
- Check out the different Memphis repositories and look for issues labeled “good first issue.”
- You can then apply the proposed changes
- Create the pull request.
These pull requisites are likely to comprise small changes, and it is unlikely for there to be multiple back and forth; at the same time, this will give you a good feel of the contribution workflow. To learn more about the contribution guide, please check out the How to Contribute? guide.
Memphis Community
The Memphis Community is composed of very kind and skillful people. In addition to GitHub, they are very active on social media platforms such as LinkedIn, Discord, and Twitter. Since day-1, people like Yaniv Ben Hemo, Idan Asulin, and Avital Trifsik have been very welcoming and understanding. They were kind enough to send me their cool swag pack as a token of their appreciation. Moreover, they helped me understand and learn different technical aspects of the event processing platform. At first, the thought of contributing could seem daunting, but speaking from experience, I assure you that you will be relieved of your worries with a community like Memphis.
Conclusion
Memphis owes much of its success to the tireless efforts of its contributors, and I am proud to be a part of this very knowledgeable and vibrant community of developers. I have been privileged to make valuable contributions to this next-generation event-processing platform. As Memphis continues to grow and evolve, there is no doubt that I will continue to contribute to the project. So, if you're a developer looking to get involved in a dynamic and exciting project, please join the Memphis community and contribute to help shape the future of event processing.
Top comments (0)