You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm starting work on a project with a Go-based backend that will be interacting with Supabase. My initial search for an existing client library led me to nedpals/supabase-go which was started circa 2021. I started applying this library to my nascent app backend until I discovered that Supabase has endorsed a community-led effort to build a client library in supabase-community/supabase-go. When I examine that repo, I see the initial commit was made in 2023. I am confused by this, and I am hoping to resolve this confusion in this discussion.
Firstly, it is clear that nedpal's effort began quite some time before the Supabase Community began their effort. As of today, his repo has ~40% more stars. Between the READMEs of supabase-community/supabase-go and its associated integrations (e.g. postgrest-go, auth-go, storage-go, and functions-go), there is no clear divergence in the goal of these efforts. There are some differences in the approach; for example, the usage of the GoTrue library or lack thereof. But I see no discussion in either community about why separate efforts are desirable—no apparent dogma differentiating the two. Nor is there any discussion about nedpals' repo becoming the Community's preferred client library, either before or after the creation of the current Community repo. If no philosophical differences in implementation exist, wouldn't it be preferable to merge the communities to form a more robust group of contributors?
I ask this coincidentally at a time where nedpals is looking to pass on the torch of ownership. I am not advocating that we do this, however. Rather, I'd like to have the conversation about why it should or shouldn't be done. I anticipate that I will become a contributor myself, but certainly not in two separate libraries that fundamentally achieve the same end goal.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hello, everyone.
I'm starting work on a project with a Go-based backend that will be interacting with Supabase. My initial search for an existing client library led me to nedpals/supabase-go which was started circa 2021. I started applying this library to my nascent app backend until I discovered that Supabase has endorsed a community-led effort to build a client library in supabase-community/supabase-go. When I examine that repo, I see the initial commit was made in 2023. I am confused by this, and I am hoping to resolve this confusion in this discussion.
Firstly, it is clear that nedpal's effort began quite some time before the Supabase Community began their effort. As of today, his repo has ~40% more stars. Between the READMEs of supabase-community/supabase-go and its associated integrations (e.g. postgrest-go, auth-go, storage-go, and functions-go), there is no clear divergence in the goal of these efforts. There are some differences in the approach; for example, the usage of the GoTrue library or lack thereof. But I see no discussion in either community about why separate efforts are desirable—no apparent dogma differentiating the two. Nor is there any discussion about nedpals' repo becoming the Community's preferred client library, either before or after the creation of the current Community repo. If no philosophical differences in implementation exist, wouldn't it be preferable to merge the communities to form a more robust group of contributors?
I ask this coincidentally at a time where nedpals is looking to pass on the torch of ownership. I am not advocating that we do this, however. Rather, I'd like to have the conversation about why it should or shouldn't be done. I anticipate that I will become a contributor myself, but certainly not in two separate libraries that fundamentally achieve the same end goal.
For reference, I initially asked about this in the recent nedpals/supabase-go issue entitled "Looking for new maintainers/owners for supabase-go".
Beta Was this translation helpful? Give feedback.
All reactions