Here is what you need to know:
- Swift, Kotlin, C#, and Python are now stable.
- We’ve added even more support for mobile using React Native and Expo.
- We’re consolidating all client libraries onto the same version number (v2) so that you get a consistent API across all libraries.
All of the libraries mentioned in this post are now on v2. We want the API for each library to “move in lock step”. You should be able to jump around each of the client libraries and they should operate the same, barring any language idiosyncrasies.
Supabase Python is now stable thanks to the following maintainers: Anand, Daniel Reinón García, Leynier Gutiérrez González, Joel Lee, and Andrew Smith.
Check out the docs, as well as these Python examples to help you get started:
- Slack Consolidate: a slackbot built with Python and Supabase
- Python data loading with Supabase
- GitHub OAuth in your Python Flask app
Supabase Swift is now stable thanks to Guilherme Souza and Maail.
Check out the docs, as well as these Swift examples to help you get started:
- Getting started with Swift
- iOS Swift Database & Auth (video tutorial)
Supabase Kotlin is now stable thanks to Jan Tennert
Check out the docs, as well as these Kotlin guides to help you get started:
We’ve made several updates for Typescript support in supabase-js:
- the Supabase CLI now generates Table and Enum shorthands
- new helpers
QueryResultandQueryDataextract the result types for complex queries and joins - relationships between tables are now supported:
- one-to-many relationships are typed as
T[] - many-to-one relationships are typed as
T | null
- one-to-many relationships are typed as
The core theme of Flutter v2 has been stability and better DX. Shout-out to Vinzent, a community maintainer who has done the majority of the work. Some notable improvements:
- Type safety for queries: The return type of a query will automatically be set to
ListofMapdepending on return type (single()ormaybeSingle()) - Type safety for Realtime: Realtime broadcast and presence get their own methods to make it more easily accessible.
- Performance:
- Initialization time has been reduced by lazily refreshing the session in the background.
- Lighter package size. We have removed some dependencies
We’ve worked with the Expo team to improve support for React Native.
By default, supabase-js uses the browser's localStorage mechanism to persist the user's session. This can be extended with platform-specific implementations. React Native can target native mobile and web applications with the same code base, so we need a storage implementation that works for all these platforms. Now you can use react-native-async-storage or a combination with expo-secure-sorage for AES encrypted sessions.
Beyond that we’ve focused on making supabase-js highly compatible with React Native and created plenty of video tutorials and documentation for:
- crafting an offline-first experience
- uploading files to Supabase Storage
- sending push notifications.
We have a strong preference to develop the client libraries with our community. This is part of our open source philosophy:
The Cathedral or the Bazaar?#
If you haven’t already, it’s worth reading “The Cathedral and the Bazaar” by Eric S. Raymond. In short, it contrasts two software development approaches:
- The Cathedral represents closed, centralized development, where a small group of developers work in isolation.
- The Bazaar symbolizes open, decentralized collaboration, where a large community of developers openly shares and collaborates on code.
We believe the “bazaar” model is the right model for an open source business. If you aren’t constantly pushing in this direction then it’s extremely likely that the company will relicense (seen most recently with Hashi). The way we see it, the more we can foster our community the less power we have.
We just reached 1000 contributors to our main repo. It’s not easy to build a community of contributors, it’s something that need to be fostered. (Shout out to @tobiastornros, contributor #1000 - and everyone else who contributed yesterday)
The client libs are one of the best ways to foster the community because they are lower-complexity than some of the tools we maintain (do you know Haskell?).
We want the Supabase community to outlive us. With more community maintainers, you should feel even safer knowing that there is already a continuity plan in place. We’re giving back to the community and we hope to expand this as we become even more commercially successful.
Modularity#
As a Principle, we develop a library for each tool we support. While Supabase may “feel” like a single tool when you’re using it, it's actually a set of tools which you can use independently (especially useful for self hosting):
We have libraries for each of the middleware components. For example, supabase-js is simply a wrapper around postgres-js, storage-js, etc. If you want to self-host PostgREST with your database, it should feel very familiar:
_10
// supabase-js
_10
const supabase = createClient('SUPABASE_URL', 'SUPABASE_KEY')
_10
const { data } = supabase.from('countries').select('id, name')
_10
_10
// postgres-js
_10
const postgrest = new PostgrestClient('POSTGREST_URL')
_10
const { data } = postgrest.from('countries').select('id, name')
Why not auto-generate the libraries?#
We’re not completely against this idea, but from what we’ve seen so far:
- Each language has its idiosyncrasies. Developers using generated libraries often find themselves writing code that feels unnatural in their chosen language.
- Generated libraries are somewhat bloated. We want to keep the libraries extremely small.
That said, we may look into this approach in the future, perhaps starting with one of the tools.
If you want to become a maintainer, please just get started with PRs. If, after a few PRs, you enjoy the process, ping one of the teams on Discord and let us know - we’ll work with you to become a community maintainer.