Reflection on the Bard API Project

[dsdanielpark]

Thank you for loving Bard API

Your support means a lot!

1. Appreciation for Contributors

Before reflecting on the project, I want to express my gratitude to all the contributors. Especially, a big thank you to Antonio Cheang, and to everyone who enriched the Bard API with more features than I had initially envisioned.

In truth, the stars on this GitHub repository belong to all the contributors, not just me. If I could transfer GitHub stars, I would gladly send them to everyone involved.

Once again, I bow my head in gratitude to all the contributors. While I regret not maintaining the code as efficiently as I could have with my current skills, or anticipating that Bard API would remain active for so long, I will strive to become a better and more skilled developer in the future.

Also, as mentioned in the Gemini API, I apologize for moving the repository without the consent of the contributors, in pursuit of making it better. I have also added badges for all contributors to the Gemini API package.

I hope this project has been of some help to the contributors.

CBoYXD, veonua, thewh1teagle, jjkoh95, yihong0618, nishantchauhan949, MeemeeLab, https://github.com/dsdanielpark/Gemini-API/issues/9[kota113](https://github.com/kota113), sachnun, amit9021, zeelsheladiya, ayansengupta17, thecodekitchen, SalimLouDev, Qewertyy, senseibence, mirusu400, szv99, sudoAlireza

2. How Bard API Came to Be

In truth, while working as an AI engineer for several years, I had a desire to develop a package that would allow me to monitor the status of my code remotely, especially when running projects with limited computing power over weekends or after work hours. Hence, I quickly developed a package called Except Notifier, which allowed monitoring of code status remotely from various messenger apps. During this process, I also designed the Bard API to be compatible with Chat GPT and Bard, so they could be used together. (Of course, this also needs refactoring, but there's so much to do.)

Additionally, while working on Co-Coder, which returns Python and iPython errors, I wanted to enable developers to receive debugging information about errors without having to search for them. Once again, Bard API came into play during this process.

Although both packages were ambitiously prepared, they didn't receive much attention.

However, I plan to refactor both packages soon to make them more user-friendly.

3. Challenges Faced while Curating Bard API

Firstly, it was psychologically challenging not knowing when Google's application interface would change. It was the most difficult part, as I thought that even if I developed a package, it would become unusable within two months.

So, it was tough to invest so much time in the project, not knowing when it might become obsolete.

Looking back, if I had taken the time to prepare then, a quick transition to Gemini API would have been possible.

Secondly, Bard Web underwent frequent interface changes with experimental features being added and removed, leading to issues where implemented features wouldn't work due to these changes. I should have written test code to automate CI, but my fear of not knowing when things might not work prevented me from doing so easily.

Thirdly, feedback on Google account status and differences between regions/countries was the most challenging. Therefore, in an effort to quickly apply it to other cookie values or interfaces, I simply modified the existing structure and deployed it. However, I couldn't proceed easily due to the fear of creating new issues for users who downloaded and used the package due to these changes.

In essence, it was difficult because I couldn't debug various Google accounts, regions, and countries one by one.

Lastly, it was about operating the open-source community. If it had been an API I provided as a service, I would have fundamentally modified the source to prevent various issues from arising. But in reality, it was JSON hijacking, so I couldn't predict and develop various scenarios.

This also contributed to some inefficiencies and messy code.

In conclusion, reflecting on it, the package was effective for a long time, and now it's back in action with Antonio Cheang via Gemini API.

Furthermore, while restructuring Bard API, I also planned to implement it more efficiently asynchronously. However, HanaokaYuzu had been preparing for this attempt since January and implemented it cleanly, so I aim to quickly finish the new Gemini API for my personal projects and refactoring purposes.

4. Reasons Bard API Was Loved

Firstly, although it became a bit messy later on, the initial code was very lean, which I believe was effective. It was easy to pull together into various projects because it was a small structure that could be attached here and there. Also, providing easy-to-understand usage instructions in the readme and offering complete code examples in Colab might have contributed to its effectiveness.

Later on, the addition of various features by many contributors and the inclusion of gifs and various code examples to make it easier for people to use may have also been effective.

In short, the principle that easy and convenient code for me to use is easy for others to use seemed to work to some extent.
Moreover, I realized that striving for both a complex structure and user-friendly package requires a lot of consideration.

5. Personal Insights

• Providing modules for minimal usage across various projects
• Strong encapsulation from the beginning is not ideal; it's better to leave some duplication in the code so that other contributors can easily modify it (It's better to remove constants and various variables later during refactoring. If encapsulation is too strong from the beginning, it may be difficult for other contributors to modify and test it easily. (Later, it's better to separate them to catch errors and make it easier for other contributors to modify.)
• Providing easy documentation and minimum samples encourages people to use it. Therefore, it's good to assume that readers use very simple code. In other words, even if it's messy, it's better to write functions that are easy to modify.

6. Lessons Learned

• I was able to communicate with various people in the open-source project. In particular, it was interesting to see how users used my package and their derivative repositories, through which I learned how to write more efficient and better code. Since I understand the overall process of my package well, I was able to confirm these aspects and make contributions to readme when there were some parts where users declared sessions inefficiently.
• I realized that frequently asked questions were due to the unkindness of my documentation or code, so I modified the package to avoid repeated questions.
• Overall, I think it was good to make the code user-friendly even if it's messy and takes a little longer. It is also good to consider how much users will use the feature when feature requests come in and compare the development cost accordingly.
• I became a bit tired as I continued to communicate with developers of various nationalities, but it was also good to see them find answers and be passionate.

7. Conclusion

Other developers' efforts to find answers and their passion motivated me to work harder.

Once again, I sincerely thank all the contributors who have loved and contributed to this imperfect package.

I hope you all have a happy and fulfilling 2024. Stay healthy, developers! Adiós!