[HN Gopher] Supabase-JS v2
       ___________________________________________________________________
        
       Supabase-JS v2
        
       Author : samuba
       Score  : 122 points
       Date   : 2022-08-16 15:40 UTC (7 hours ago)
        
 (HTM) web link (supabase.com)
 (TXT) w3m dump (supabase.com)
        
       | joshstrange wrote:
       | I'm going to have to very kindly ask the Supabase devs to stop
       | making such an appealing development platform as I don't have the
       | time/energy to rewrite my existing web/apps.
       | 
       | 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!
        
         | kiwicopple wrote:
         | thanks for the kind words
         | 
         | 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.
        
         | zinclozenge wrote:
         | I think the best part is that if you're willing to go all in on
         | RLS for your authorization, you can do away with needing a
         | backend for your typical crud operations and use their
         | functions for things like webhooks, or the occasional endpoint
         | for more complicated operations.
        
           | alostpuppy wrote:
           | Whoa. Didn't think about that.
        
           | mildmustard wrote:
           | Absolutely.
           | 
           | 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.
        
             | Escapado wrote:
             | I am a happy paying user of supabase and I did just that
             | for my project which is meant to facilitate trading of left
             | over wood between woodworker shops. I simply set RLS rules
             | and now I only have a react frontend which calls supabase
             | directly and it works great.
             | 
             | 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. :)
        
           | beaker52 wrote:
           | I can't quite get onboard with RLS directly from the client.
           | It seems like a risky and finicky thing to design database
           | access patterns around, but they might be a stroke of genius
           | that I'm too blind to see right now.
        
       | a-user-you-like wrote:
       | What about updated Dart support and functions?
        
       | bsimpson wrote:
       | It's wild that their whole value proposition seems to be "It's a
       | Firebase clone, but open source."
        
         | zem wrote:
         | why? that has historically been an enormously popular value
         | proposition for a lot of projects!
        
       | throwaway_4ever wrote:
       | Anyone running projects with just Next.js + Supabase and no
       | traditional backend?
        
         | msdrigg wrote:
         | I tried to make this work for me, but I finally gave up this
         | week and wrote a traditional backend component for part of my
         | backend because supabase doesn't support transactions and I am
         | NOT going to write my whole backend in postgres functions.
        
           | kiwicopple wrote:
           | supabase does support transactions through RPC calls - I
           | think you already understood that based on your comment but
           | want to make the distinction clear for other readers
           | 
           | 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.
        
             | msdrigg wrote:
             | I will give deno functions a look -- I haven't really
             | looked into them.
             | 
             | 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%.
        
           | creakingstairs wrote:
           | You could hook up Prisma (or any other Orm) to Supabase and
           | use their transaction API. Though this will still need to be
           | in server part of NextJS (api routes or getServerSideProps),
           | but would be faster than rolling an entire backend.
        
       | krono wrote:
       | This article and others like it would greatly benefit from a
       | brief description of the thing it is about.
       | 
       | 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!
        
       | ZiiS wrote:
       | Much prefer the DX of the types inferring from the `from` and
       | `select`. Also really love that `insert` now understands if a
       | field is required (or has a server-side default etc.)
       | 
       | 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?
        
         | kiwicopple wrote:
         | > we seem to have lost all typing for Views
         | 
         | 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)
        
       | sweetheart wrote:
       | Chiming in with the huge props to Supabase. I'm falling in love
       | with the product, and I was also incredibly surprised at the ease
       | of porting my applications on Firebase over to Supabase using
       | their migration scripts.
       | 
       | 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!
        
       | emptysea wrote:
       | How do you limit the queries allowed in the UI aka prevent
       | someone from making a really slow / large query? Do you general
       | not use supabase directly in the UI and write an API that your
       | front end can call instead?
        
         | kiwicopple wrote:
         | you can call directly from the UI. just make sure that you have
         | Row Level Security enabled and configure the default API
         | parameters accordingly (eg, by default you can select a max of
         | 1000 rows, you can adjust this if you want).
        
       | swyx wrote:
       | congrats team! i like how you used detail/summary tags to
       | truncate the v1 vs v2 diffs.
       | 
       | > 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.
        
         | kiwicopple wrote:
         | > dev-mode assistance/hints for people who may be surprised by
         | this.
         | 
         | 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
        
       | claytongulick wrote:
       | I love supabase. The main competitor is the lesser well known
       | project directus [1]. Posting my experience with Directus here to
       | see how it compares to supabase for folks that have gone that
       | direction.
       | 
       | 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.
       | 
       | [1] https://directus.io/
        
         | kiwicopple wrote:
         | I've heard great things about Directus. We have a guide (which
         | the Directus team kindly contributed) that shows how to use
         | Directus & Supabase together:
         | https://supabase.com/docs/guides/integrations/directus
         | 
         | best of both worlds
        
       | memphischris wrote:
       | Supabase user here. Ive been happy with Supabase. It feels like
       | the recent launches have been underwhelming.
       | 
       | I am really pumped for Neon and think they are doing something
       | more differentiated.
        
         | richardfey wrote:
         | I'm curious, care to drop a link about this Neon you're
         | referring to? Thanks!
        
           | nikita wrote:
           | http://neon.tech
        
         | kiwicopple wrote:
         | sorry to underwhelm!
         | 
         | 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
        
         | asadawadia wrote:
         | are you a frontend dev?
        
         | zinclozenge wrote:
         | If all you care about is the database, then yes there's a good
         | chance that Neon will greatly outperform. But Supabase is much
         | more than that since it includes authentication, functions,
         | file storage, and their realtime feature. For me, the appeal is
         | that you can get all those features with a postgres database.
         | The nice thing is that you can mix supabase features, so if all
         | you care about is authn, you can still use it with neon.
        
       | LAC-Tech wrote:
       | I'm having a bit of difficulty understanding what supabase is.
       | 
       | 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?
        
         | kiwicopple wrote:
         | yes you're right. The JS library is a thin wrapper around
         | PostgREST's API (https://github.com/supabase/postgrest-js)
         | 
         | 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
        
           | LAC-Tech wrote:
           | Ok that puts in perspective. It's a convenience package not a
           | must have.
        
         | tfsh wrote:
         | The JS library is an interface to the HTTP API which handles
         | functionality such as authentication, querying (and the likes)
         | and more complex functionality such as real-time updates. I
         | notice V2 also included auto-generated type defs for various
         | table columns
        
       | bicijay wrote:
       | I love supabase and im using it on one of my projects. The only
       | downside is the storage abstraction on top of S3, those Egress
       | fees are huge. I would love to see a Backblaze b2 integration.
        
         | kiwicopple wrote:
         | > Backblaze b2 integration
         | 
         | 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!
        
       | cjblomqvist wrote:
       | Maybe it's been discussed before but since it's a VC backed
       | company, what's their business model? They raised a ton of money.
       | How do they plan on getting that back?
        
         | kiwicopple wrote:
         | supabase ceo here.
         | 
         | 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
        
           | nkmnz wrote:
           | Where does the actual hosting happen? AWS?
        
             | kiwicopple wrote:
             | yes, just aws for now.
        
         | cercatrova wrote:
         | Firebase clone but open source, with hosted options. It's a
         | very valuable value proposition that many people including
         | myself are looking for.
        
         | swyx wrote:
         | its brought up every time supa is on hn. reasonable qtn but
         | here you go https://news.ycombinator.com/item?id=32440018
        
           | rglover wrote:
           | Your answer didn't answer anything and was a bit terse. Their
           | question was valid.
           | 
           | 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.
        
             | kiwicopple wrote:
             | supabase ceo here - you're right about the hosted option,
             | but we don't charge any license fees.
             | 
             | 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
        
         | replygirl wrote:
         | their whole thing seems to be to capitalize on rightful faang
         | skepticism to become the default paas over firebase. the model
         | is same as any other paas. going off my network it appears to
         | be working, but making the whole sell "we're open source" makes
         | me wonder if it'll still be a leader in 5-10 years
        
       | jackconsidine wrote:
       | I love the concept of Supabase. The Firebase model is powerful
       | but gated. For example, I recently had a project exceed FB's
       | quota of functions- you can't deploy more than 60 endpoints in a
       | minute which is a nightmare for CI pipelines which redeploy the
       | entire app [0].
       | 
       | 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.
       | 
       | [0] https://firebase.google.com/docs/functions/quotas
        
         | kiwicopple wrote:
         | supabase ceo here
         | 
         | > Intermittent network errors
         | 
         | I'm curious about where you're seeing these errors - is this
         | your database functions or "Edge Functions" (Deno)?
        
         | ishanr wrote:
         | I use supabase as our backend for https://sudopad.com and
         | recently crossed 1000 shared links. Has been pretty stable for
         | me. The only thing I am waiting for is the ability to call a
         | subabase function on db change.
        
         | latchkey wrote:
         | Why not have a single function that uses a router? Just map /*
         | to the function and within the function, make your calls to
         | other discrete handlers.
        
           | jackconsidine wrote:
           | That is the exact solution we went with :)
        
             | latchkey wrote:
             | So then why mention that FB is gated? It isn't gated, the
             | design of your application was off.
        
               | ibero wrote:
               | it is gated. 60 endpoints in a minute. thanks to OP i now
               | know this.
        
               | latchkey wrote:
               | Sure, maybe I'm reacting more to calling it a nightmare.
               | This is a well documented limit.
               | 
               | 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...
        
               | jackconsidine wrote:
               | This is obviously a (hacky) work-around. Firebase
               | Functions are designed to be deployed individually-
               | abandoning that costs you GCP log traces and boilerplate
               | right off the bat. Read the Firebase Functions
               | documentation, and you'll see no mention of designing
               | your application this way.
        
               | latchkey wrote:
               | I always assumed it wasn't documented as such because it
               | is a bit more complicated to set up / describe and they
               | were trying to keep the docs simple.
               | 
               | 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.
        
         | no_wizard wrote:
         | I fundamentally disagree with this limit due to the fact they
         | provide no alternative when you start getting into that area (I
         | imagine scaling to 120 or 180 is going to be painful for
         | instance). I'm really shocked they don't have a way for a
         | customer to get this quota changed if on an enterprise account
         | for instance (usually there is some byline to the effect of "if
         | you need a higher quota please contact your account rep" sort
         | of thing, but there is none of that here, which tells me no
         | matter the size this is ironclad)
         | 
         | 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?
        
       | a-user-you-like wrote:
       | Any support for https://flutterflow.io/ coming?
        
       | jadbox wrote:
       | Has any used Fly.io app hosting with Supabase-JS for the DB? I'm
       | curious to hear people's experience.
        
         | kiwicopple wrote:
         | I created a branch to deploy the supabase "postgres" image
         | (with all extensions etc) here:
         | https://github.com/kiwicopple/postgres-ha/pull/1
         | 
         | It worked great. That's just the database part - from there
         | you'll need to deploy the middleware too
        
       | throwawaysupa wrote:
        
       ___________________________________________________________________
       (page generated 2022-08-16 23:00 UTC)