Looking for new maintainers/owners for supabase-go

[nedpals]

Hi everyone,

I'm writing to let you know that I'm no longer able to maintain this repository. I haven't used Supabase for over a year now and my focus has shifted to other projects.

I apologize for the number of outstanding issues and pull requests. I know this has been frustrating for many of you, and I'm truly sorry for not being able to address them in a timely manner.

I'm looking for new maintainers or owners who are willing to take over this project. If you're interested, please contact me directly. We can discuss transferring ownership of the repository.

v0.5.0 will be my last release for this project.

Here are some areas where the project could benefit from some love:

• Migration to supabase-community/postgrest-go: This would align the project with the community-maintained PostgREST client and potentially reduce maintenance overhead.
• Improved test coverage: Adding more comprehensive tests would increase the stability and reliability of the library.
• Documentation updates: Ensuring the documentation is up-to-date with the latest Supabase changes would be very helpful for users.

I believe this project can still be a valuable resource for the Supabase community, and I hope someone will be able to step up and give it the attention it deserves.

Thanks for your understanding.

[antoineross]

Hi @nedpals,

I've been using the the official supabase-go client for a while now and I feel that this package is much more advanced and would like to update it up to parity with supabase-js (in some aspects like realtime). Will take a look at the package over the weekend and try implementing it in some projects to have a better understanding.

Let's have a chat over the roadmap some time soon?

Cheers, really appreciate the work you did here.

[nedpals]

@antoineross Hi! Thank you for your interest. For the sake of transparency and spirit of open source, we'll discuss this publicly.

Given that I haven't given attention for a while now, I can say that there is no definite roadmap other than the ones mentioned above. Hope that helps!

[nallj]

Hi there, @nedpals.

I'm starting work on a project with a Go-based backend that will be interacting with Supabase. I've been trying to evaluate the difference between your project and the community-backed supabase-go. From what I can tell, your library is focused on simplicity, and it was created much earlier (2021 vs 2023). I didn't realize there was a community-backed version, so I started using your library and I was fairly pleased with its ease-of-use.

When I discovered the community-based project, my immediate feeling was to switch to that since it's being referenced by Supabase themselves on the same page as their official versions. It makes sense that kind of endorsement would lead to more attention in the long run. Still, your project has ~40% more stars at this time. And a cursory look at their ecosystem lists other libraries (e.g. postgrest-go, auth-go, storage-go, and functions-go) that appear to be integrated into supabase-go in ways I don't readily understand. The auth-go package in particular claims

This library is a pre-release work in progress. It has not been thoroughly tested, and the API may be subject to breaking changes, and so it should not be used in production.

which is cause for concern to me. I'm a one-person team, so efficiency is important to me.

In summary, I'm not sure which project I should use since neither are fully mature. Whichever I choose, I will most likely contribute to in order to enable my project. Can you please help me understand the difference in goals of these projects? Why does your project persist when there's another project that's more "endorsed", especially considering that your life situation has changed and you can no longer carry out your vision? Or, perhaps it's more appropriate to ask why your project wasn't endorsed by the "Supabase Community"? Really, any insight you can provide will be much appreciated by me, and I suspect others in a similar position.

[nedpals]

Hi @nallj and thanks for taking the time to share your thoughts.

I created this library for my (now cancelled) project back when Supabase was still in its early stages. Someone already built a postgrest client for Go so I took the shot. I already reached out to Supabase more than a year ago to support my work. We had some discussions already but they did not respond after my last reply. (Partly my fault I did not follow-up)

As for why people still prefer this over the community-made version, as you've said this was created way earlier before the mentioned version. As a result, many tutorials were already created for my version of this library.

Edit: My door is still open for transfering this to the supabase-community.

[nallj]

Interesting. I went ahead and opened a discussion within the Supabase Community to see if anyone has any further context over there. It's not apparent to me why these two efforts should be separate and there would be several benefits to merging the efforts together.

[antoineross]

Hi @nedpals here are some of the following changes I would like to implement:

• We should follow the format of JS SDK as much as possible. The client creation of supabase-go is a much closer implementation of this. This uses postgres-go as well, something we're looking to do.
• Update the current use of gotrue-go → auth-go from the supabase-community.
• We want to keep the update_user, SignInWithProvider and other similar functions from your package. We just need to update them to use auth-go and the client creation from current supabase-go package.

The goal is to make a version that copies the best practice from both repos pragmatically.

As a side note, I'm looking to implement this as soon as holidays end. Will create a fork of supabase-go then make a lot of updates from there. Not looking to force such a breaking change here if you're not keen to it. Let me know what you think about this direction, happy to discuss.

[nedpals]

@antoineross Your suggestions sounds good to me. Indeed, these changes makes it more possible to be integrated into the supabase-community version should a merge happen.

Feel free to submit your PRs here and keep them as small and as focused as possible so we can minimize any breaking changes. Best of luck 👊

[antoineross]

@nedpals I made a quick fork of supabase-go, added SignInWithProvider and upgraded it to use auth-go.
See my fork here: https://github.com/antoineross/supabase-go.

This will be the base, then I can add the rest of your functions sometime later next week. Let me know if this looks promising to you.

[antoineross]

My ultimate goal is to get the ball rolling for updating the package as I don't see any interest from the community. It's much better as well to work in a repository with a lot of eyes on it from the get-go.

[nallj]

@antoineross Yes, I'm a little disappointed that there hasn't been any kind of response to my message over in the community. I'm hoping that it's just because it's the holidays.

I have a question about your swapping of gotrue-go with auth-go. I notice in the README of the community repo that gotrue-go is listed, but when you go to the community homepage, you see auto-go listed. This confused me initially. My confusion was further compounded by this note in auth-go's README:

This library is a pre-release work in progress. It has not been thoroughly tested, and the API may be subject to breaking changes, and so it should not be used in production.

On the surface, I don't see why they would recommend not using this in production. If we have concerns about the reliability of its functionality, as consumers of the project we should contribute tests. And if the API of the client changes, you either upgrade your package and change your usage or (less preferably) don't upgrade the package. Still, it's a bit daunting to see the package maintainers suggest not using this package in a production app. Anyway, I bring this up to ask if it's wise at this juncture to incorporate the usage of auth-go into nedpal's project at this time given its lack of maturity?

[antoineross]

Auth-go is a fork of gotrue-go, it's only 2 commits ahead both of which are minimal and non-breaking. They are both tagged with "pre-release". You're free to test it, I have it running on my system and works fine — will double check all functionalities so it aligns with the official supabase examples for auth.

As for whether it should be incorporated, it's a design choice. Current implementation is very direct with all functionalities in one codebase. What we (I particularly for modularity) want is there should be a separation of concerns for auth/postgrest/client rather then keeping all of them in one place.

Please see the difference in auth-go client vs with this repo, there's a lot of missing functionalities here that can be added and should be. From my understanding auth-go is more mature and updated as compared to current auth implementation.

[nallj]

@antoineross Thank you for the insights. I'm just now realizing that I may have been reading some of this thread incorrectly, largely due to both the community and nedpal's repos being named exactly the same. Were you suggesting that future work should be done in the community's repo as opposed to here?

[antoineross]

I suggest that we use the packages from the community as a base. As for the nedpals package, we can adopt the practice of making it as close to the supabase-js client as much as possible.

Why use community package as a base? It's more mature. Community auth package, for example, hits more endpoints we can use. Plus with already defined types.

The question now is whether we should use the supabase-go official community package or nedpals. For me, either is fine. I will work on whichever allows me to move it forward as much as possible.

I already have existing code on my supabase-go fork which you can use as a reference on what I mean by closer to supabase-js client.