Supabase-JS v2
supabase.com
supabase.com
But for real, congrats on this and it looks very nice. At this point I'm just waiting on a new project that would be a good fit so I can play with all of this. Keep up the great work!
I find myself saying this a lot when I try and explain the concept of Supabase. We don't really emphasize this very much on our website either.
Disclaimer: I work at Supabase.
I haven't checked in a while but one thing that was a little cumbersome for me was that I wasn't familiar with writing proper RLS rules and felt like documentation was a bit sparse and iirc there was not autocomplete to guide me a little more - but that might just be me being an idiot and it worked out with a little trial and error. :)
v2 isn't a huge change from v1, if you have anything existing that you need to migrate. The Typescript support should be quick/easy (if you used it in v1, it's mostly removing <Type> from a bunch of your methods). A lot of this is preparing for mutliplayer functionality (coming on thursday) - we needed a breaking change to support Phoenix's presence/broadcast interface.
We recently tried Supabase on a "frontier" project, and found that it wasn't quite mature enough for production use in our case. Intermittent network errors and lack of an up-to-date status page hampered productivity a bit. These API changes seem like steps in the right direction.
First thing I always do is read the quotas/limits on any google cloud product before I use it.
Then, I'd notice the increase in deployment times on my CI server as more functions were being added and inspect what was taking so long and try to optimize it. Those individual endpoints take a while to deploy...
Once you get past a certain amount of endpoints, I'd always want to declare my endpoints in code rather than be tied to their config.
Never had an issue with the logs. Requests still show up.
> Intermittent network errors
I'm curious about where you're seeing these errors - is this your database functions or "Edge Functions" (Deno)?
Off topic but I am curious:
Why re-deployed unchanged code?
The user-land solution I can think of is cached builds that only re-deploy changed code?
It's a second release candidate, there are instructions for how to install it, apparently it's really popular (congratulations btw :)), but there's no mention of its actual purpose. Could be another JS engine, a new Postgres JS extension, or who knows what else.
Wouldn't have hurt to get the GitHub repo description "An isomorphic Javascript client for Supabase." in there somewhere!
I assume for the File Storage? We've designed this server for additional storage providers, and since Backblaze is s3-compatible it shouldn't be too hard to add. Would love a PR if you're up for a challenge!
I cannot recommend their platform enough to anyone who hasn't tried it yet! It's going to be my platform of choice for all my upcoming projects. Keep it up!
I had a tough time picking between these, but ended up landing on directus for a few reasons:
1) I don't like using db level users for RLS. Directus has a traditional users table that can be expanded with anything you want, and their roles ability is pretty comprehensive. Column level security is also straight forward based on declarative rules.
2) The Directus admin app is second to none, other than perhaps Django. Its extensibility is the real killer feature. I'm in production right now with nothing but the admin app and a set of extensions.
3) The files and storage capabilities support pretty much any mechanism you could dream up, plus build-in image editors etc...
4) The flows capability gives semi-technical users the ability to do IFTTT like logic inside the admin app. Pretty cool.
5) Directus has a (very) basic BI capability, that's extensible, and tied into the permissions model.
6) This is just a personal preference, but Directus is a smaller company and operating on less funding. This means that we're able to sponsor issues that are important to us and we can communicate directly with core team members. The team there has been extraordinarily responsive, and their github repo is the gold standard in community engagement, imho.
7) The deployment model is a breeze. Just a package.json dependency. npm install does everything.
Downsides:
- They fairly recently rewrote the whole platform from PHP to NodeJS. I applaud the decision, but this means that the product hasn't reached the same level of maturity.
- QA: the Directus team moves fast and breaks things. We've encountered several situations where releases have come out with core functionality broken. We've learned to thoroughly QA a release before we update.
- DX: the developer experience for writing and debugging extensions isn't the best. Its also very opinionated about Vue. I'm currently operating off a fork so that I can have a better DX and use Web Components (fortunately vue plays well with them). If you're just using out of the box functionality and the API, this isn't an issue.
best of both worlds
I'm going to look deeper at supabase and how it can add to our stack.
Pretty excited about the sql query editor.
I thought it was a Postgres database that gave you a PostgREST HTTP API interface.
If that's the case... what does the javascript library do?
Supabase now offers a few more features which integrate with the Postgres database - File Storage (s3), Authentication, Deno Functions, and Realtime (database change listeners). Each of these services is a standalone server and each has a corresponding JS library.
"supabase-js" wraps up the modular JS libraries into a single library for convenience
In their FAQs they argue that you can just use JSON columns in Postgres but that doesn't really solve my issue because those columns would still need to be pre-defined.
It worked great. That's just the database part - from there you'll need to deploy the middleware too
Unless I am missing something we seem to have lost all typing for Views? And it is less clear how to use PostREST style embedding?
I've sent this to the team. We generate the types directly from database, so it's definitely possible.
> PostREST style embedding
For now, you'll need to do something like this:
https://supabase.com/docs/reference/javascript/next/typescri...
In future releases I think we'll have an approach which doesn't require any manual intervention, but for this release we wanted to keep the upgrade path relatively simple (it will probably require us to change from strings - `select('id, name')` - to objects)
I know Supbase is a sponsor of the PostgREST.
We are a sponsor and we employ the maintainer of PostgREST
You can also be fully restrictive by only allowing the client to call the custom SQL functions[2] you define. In Supabase this is done by having all your tables in a "private" schema and only SQL functions in the "public" schema(whose db objects get exposed to the client).
[1]: https://postgrest.org/en/stable/api.html#custom-queries
I can completely understand if you don't to write everything in pgpsql though. Did you also try the Deno Functions?
We've been brainstorming ways to support transactions directly from the client libs in a way that won't lock up the database if there is a network failure between database operations. It seems doable, but not something we want to rush.
And for the record I am still loving supabase overall. PostgREST works for 90% of what I want to do and I can spin up a simple stateless backend to support the other 10%.
> It is a bit surprising that you need to add a select policy to do an insert, so we opted for the “principle of least surprise”. If you don't append select(), the data value will be an empty object: {}.
i wonder if there will be dev-mode assistance/hints for people who may be surprised by this.
I'm very excited for the multiplayer features you teased. it looks to be increasingly table stakes for any app, and people shouldn't be handrolling this stuff.
We mostly rely on Postgres' errors to bubble up through the client libs which, coincidentally, is one of the things we've improved in this release. Most of the servers now are passing the Postgres errors through, and we're standardizing on the Postgres error format.
There's a lot more we can be doing here, but it's a step in the right direction
It looks like the answer is that they're charging some sort of licensing fee per project using Supabase or that they have a hosted option for people who don't want to run their own Supabase instance(s): https://supabase.com/pricing.
Supabase is very liberally licensed (MIT, Apache2, PostgreSQL, depending on the tool), and we don't plan to pursue any revenue from licensing. We make enough money from database hosting.
hope that clears things up a bit
we have a hosted platform - you can sign up and spin up a postgres database, and we charge you $25/month (+ additional usage over a certain quota).
This model is proving to be fine for us. It's very common for developers to pay for a database, especially a full Postgres database (more-so than say, a frontend hosting solution). We have a free tier too, where we pause the database if it is unused for a week. This good for the planet, and our bottom-line
I am really pumped for Neon and think they are doing something more differentiated.
if you like Neon, then I imagine you like their database branching model? On Friday we announced[0] our 500K investment into OrioleDB, who are working on branching[1], with the plan to upstream these changes into Postgres core.
It would be possible for us to run a fork of Postgres today which supports branching, but our long-term view is that developers would prefer a non-forked version of Postgres (to mitigate any risk of lock-in). So we will work on adding branching to Postgres core in the background, which will be a benefit to the entire Postgres ecosystem.
[0] Announcement:https://supabase.com/blog/supabase-series-b#where-were-going
[1] https://github.com/orioledb/orioledb/wiki/Database-branching
more details here: https://supabase.com/docs/architecture
I agree with Krono & jibprof about a brief description, please create an about or a better mission statement (other then "open source firebase") on the main page.
and congratz on funding kia ora!
(i’m the github complainer)