Hi guys, I was checking your Supabase Functions up...
# off-topic
d
Hi guys, I was checking your Supabase Functions update article from July, and in the timeline you mention that Supabase Functions will release in Q4 for "Early preview customers" (tier that I'm not familiar with), and that made me wonder 1) if you have plans to open source the Supabase Functions functionality in a way that can be self hosted. 2) Since there are clearly different release timelines for different types of customers, what will be the general expectation for self hosted users as to when the new features will be made a ailable to them, that assuming that all the features will be made available to all users, if not, how will self hosted uses know which features they won't be receiving ever? Thanks in advance 🙏
c
>
> if you have plans to open source Yes, whatever we do with Functions will be open source. There are a few options available with Kong already which we will explore: https://docs.konghq.com/hub/ > what will be the general expectation for self hosted users Whatever we do will probably be available immediately for self hosting, with some big caveats that there will be breaking changes. We're learn this lesson with the UI - it's much easier to start in public than to try unravel private code later on. It's a bit slower to push out features but better for everyone in the long-term > features they won't be receiving ever The goal is for all features to be available for self-hosting. The hosted platform is just a convenient way to get started. Some things don't lend themselves well to a self-hosted solution though. For example a CDN - this is something we will provide on the hosted platform however there isn't really a way to
docker-compose up global_cdn.yml
. Even Supabase will need to work with proprietary vendors for this functionality
d
Thank you @copple for the detailed response! It all sounds fair to me. Breaking changes are the bread and butter of most software projects for new major versions. As long as there is a clear upgrade path that should not be a problem. I guess that it makes sense for storage to work with external providers, and leave it for the community to implement a local storage implementation if there is demand for it. I presume that the idea of functions that you're considering will work with containers, in a firebase fashion, and therefore won't require restarting the service after deploying a new function, right?
c
> therefore won't require restarting the service after deploying a new function I can't give you a details yet because tbh we haven't made it yet. But in terms of DX, I think the best idea is to have a "versioned history" of your Functions so that you can jump back between versions. Under this model there would be no need to "restart", its just a new function with a stateless deploy
d
Sounds good to me, thank you for the info!