"Do not fear mistakes. You will know failure. Continue to reach out." — Benjamin Franklin
Hello everyone, first of all, I will like to tender a sincere apology to everyone who downloaded the Net.Facebook package and it ended up not making their work easier because that was the purpose for which the package was created in the first place, to make working with Facebook Graph API easier for .Net developers.
I made a few mistakes that cost the Net.Facebook package to be depreciated and I would like to address a few things in this article:
What is the Net.Facebook package and why was it created anyway
What went wrong
Lessons Learnt
Moving Forward from this failure.
What is the Net.Facebook package and why was it created anyway
The Net.Facebook is a package that contains a list of APIs that are used to get data into and out of the Facebook platform, the intended purpose of the package is to allow .Net developers to easily query data, post new stories, manage ads, upload photos, and perform a wide variety of other tasks on Facebook.
The Catalyst
I wanted to work on a feature that allows a system to automatically post blog contents to the company's official Facebook page daily so i needed to make use of the Posts API, this API allows developers to perform actions like posting to a page, reading posts from a page, I remember going through the docs for hours, and going through the long process of getting a few accesses and tokens, then settling to write the code.
I was able to get it to work but I thought ok, this was a bit tedious, why not save other developers the stress by just creating a package that allows people to make use of the Posts API ( for starters ), then if the feedback is encouraging I can decide to just go all in and introduce other APIs, and well, the total downloads the package got after 3 months showed me that developers really needed this package, it got about 1.3k downloads
But I got occupied and I forgot about the package, until March 2022 when I decided to check and see how the package was doing, then boom I got a notification saying This package has been depreciated as it has critical bugs.
What went wrong
The Net.Facebook was my very first package, prior to this, I hadn't written or built any package, so it was quite easy to make mistakes ( even though this didn't occur to me at the time ), I did some research but it appears it wasn't enough, as I have worked on another package and so far this package has zero complaints mainly because of the lessons learned from the depreciation of the Net.Facebook package.
Lessons Learnt
Here is a list of lessons or tips that I think .Net developers can use when building their next package/library
Read other developers code
This helped me to see how people structure their codebase for the packages they were creating, I realized that there is no one way to structure your codebase when creating packages but you can pick a leaf from how others did theirs and see how you can architect your codebase to be better, one thing i also found very common is that they
Write unit tests
I saw unit tests a lot, all these developers all wrote unit tests which was something i didn't do at the time which isn't a good practice at all, next good practice is to
Write inline comments and documentation
This cannot be overstated, an inline comment explains what a method/class is for, it can come in many different ways but below is a simple example of commenting on a method
When a user is about to use a method from your library comments can show them:
a summary of the method
the parameters that the method is expecting
what the method is returning
And documentation on the other hand can also walk your users through how to inject specific dependencies ( if any ) in their project and an overall explanation of how to get started using your package and many more, this is a good example of what good documentation looks like, or if you like Gitbook, this is also another good example. Another good practice is to
Use Access Modifiers properly (important)
Most, if not all of the methods, classes in your package/library code should be internal or private, we should not be leaking anything to the users, take for instance when we declare a method as public and we later change the accessibility to private, we might be breaking the code which would be an issue for the user and the only way to fix it will be to update a new version, speaking about versions, the last good practice is
Codebase versioning
This is actually a little controversial in my opinion as different needs might call for different decisions, between the last 13 months, Facebook Graph API has gone from version 11.0 to version 13.0, now in the early stages, this didn't mean that you had to dump v11.0 immediately for v13.0, so when building packages, i think it is a good idea to have different versions of each update so you don't break the code of the developers using your application unless it is extremely necessary to not have different versions. For the sake of context
We have V1,it contains the latest code, services, and dependencies that support all things related to V1, V2, on the other hand, might have a few changes, possibly the addition/removal of parameters, messages, or responses that are not supported in V1, so instead of having just one version that changes as Facebook ( for example ) updates their APIs by removing something which will, in turn, break our users' code, we can have another version which will only cater for Facebook's latest changes, but note that a large part of our code must be very much reuseable.
These are the few lessons i personally learned after building the Net.Facebook package.
Moving Forward from this failure
Like the Benjamin Franklin quote said at the beginning of this article, i have made mistakes, and failed, but i want to Continue reaching out, and one way i plan on doing that is to rebuild the Net.Facebook package with fresh eyes but this time to make it open source and have more people contribute to building a tool that i believe will make the lives of fellow .Net developers trying to interact with Facebook easier as intended.
Thanks for reading this little piece, and i hope to see you soon.