[HN Gopher] Supabase Edge Runtime: Self-Hosted Deno Functions
___________________________________________________________________
Supabase Edge Runtime: Self-Hosted Deno Functions
Author : creativedg
Score : 274 points
Date : 2023-04-11 13:57 UTC (9 hours ago)
(HTM) web link (supabase.com)
(TXT) w3m dump (supabase.com)
| samuelstros wrote:
| just use a regular server for mid/larger sized apps.
|
| i started my web dev journey with JAMStack, Vercel, the "edge".
| everything is easy as long as one only deploys a full-stack
| NextJS app. the moment other apps come in, just use a server
| deployed as VPS and avoid "edge runtime hell". edge runtime hell
| refers to "you can't do this (function with over 2MB payload),
| you can't do that (because not supported by X)".
|
| EDIT: I implicitly meant with "deploy as VPS" -> deploy your
| server via Render/Heroku/CI-CD instead of serverless functions
| running on the "edge".
| umaar wrote:
| I have stuck with cheap VPS servers for as long as I can
| remember. It takes 5 minutes to deploy a full stack node.js
| app, along with a database - and I've yet to exhaust the
| resources on my VPS, even with all my side projects (production
| grade and hobby stuff).
|
| Have always found it weird how so many heroku-style hosting
| providers charge _per app_, things get costly, quickly, when
| you have lots of small apps like I do.
|
| Just yesterday I realised I'll need a database to store job
| queues for https://chatbling.net - ChatGPT helped me figure out
| how to install it, have it persist to disk, ensure it starts up
| with the system etc. It's nice to not be fearful of unexpected
| charges hitting my card.
|
| To anyone reading, even if it's just for learning, every now
| and then, skip the
| vercel/fly.io/netlify/planetscale/upstash/render/railway
| whatever cool hosting provider is out, and give a $5 VPS a try.
| diamondfist25 wrote:
| These PaaScost an arms and a leg and each one have their own
| DSL u have to learn.
|
| Easiest is to just provision ur own vps and run a docker-
| compose or k8s
| llambda wrote:
| I'm coming around to building everything for a VPS from the
| outset. There's a lot of upside to VPSes, such as:
|
| 1. Can be purchased as a fixed cost, usually at a rate that's
| much cheaper than on-demand pricing, and especially serverless
| --this tends to only get better with time as competition keeps
| prices low
|
| 2. It's "just" a Unix/Windows/Mac box, so the issues with
| runtime constraints you mention are bounded differently (and
| often more favorably); serverless is also just a box, but the
| constraints tend to be more onerous and limiting and it's not
| usually accessible in the same way
|
| 3. With containers, it's trivial to move between providers, so
| the hardware itself becomes fungible
|
| 4. On containers, I'm having a great time shipping Docker
| Compose configs--this works really well for the scale of
| application I'm targeting while avoiding the dreaded complexity
| of e.g. k8s
|
| 5. There's decades of high quality tooling already built and
| battle tested which makes operating VPSes much easier; the fact
| you can SSH into the machine, for instance, has huge leverage
| as an solo person working on independent products
|
| Going forward, I'm planning to skip edge compute altogether
| unless there's a really compelling reason to want it. I should
| also mention that when a VPS is paired with a CDN, you can
| layer on bits of "edge compute" where it's warranted; or, you
| know, use it to cache static assets close to your users. :)
|
| All-in-all it's kind of a funny return to where I started ~20
| years or so ago with web development.
| 015a wrote:
| > usually at a rate that's much cheaper than on-demand
| pricing
|
| This is an area that is legitimate swindling/inflation by
| hosted app providers (e.g. DO Apps, Heroku, Render, Fly,
| etc). Oftentimes the per-vCPU/memory price is inflated over
| the underlying cost, even relative to a rather expensive
| underlying provider like AWS; which they'll reasonably
| justify by saying that this is the value-add, yeah you pay
| more but its more managed. But: when you have underlying
| access to the VPS, you can host more than one process! Which,
| of course, they're oftentimes doing on their end to cut
| costs.
|
| Serverless functions can legitimately fall into the "always
| cheaper" category. If you've got twenty apps that each get
| request volume in the range of dozens-to-thousands per month;
| you could host that on a $5/mo VPS, or you could pay a few
| cents for a FaaS (Lambda, GCP, Cloudflare Workers, etc, all
| priced in the same magnitude). But the price-to-scale chart
| of serverless functions is really weird; they do hit a point
| where they're more expensive than just, you know, running a
| web server on a VPS. That point isn't at a super low volume,
| but its not far off from where its something to think about
| for a typical software organization. If I had a personal
| project that hit that point, I'd classify it as a good
| problem to have.
|
| I also feel endless frustration in how there legit isn't a
| single cloud provider out there that (1) offers a serverless
| functions runtime, and (2) gives you the ability to set a
| non-zero budget which turns off the world when you go over
| budget. Many offer free tiers with no credit card, and some
| are even generous (Vercel and Firebase are two good
| examples), but I won't build on a free tier. I want to pay
| you. So, you upgrade and give a credit card, and now you're
| liable for one fuck-up bankrupting you, or throwing you on
| your knees at the mercy of their customer support. The
| severity of this fuck-up ranges from "my GCP account does
| just use a VPS, but egress is unlimited, so the bill was a
| bit high this month" to "the new dev changed a lambda
| function to call another which called the first one, and our
| bill is now the GDP of a developing nation-state".
|
| The vast majority of the managed infrastructure world is,
| unfortunately, B2B swindlers just trying to out-swindle each
| other, only possible because they're all buying from each
| other, constantly raising prices, finding new ways to bill
| their customers, and losing any grip on the true (extremely
| low) reality of their costs. Supabase is better than most. I
| really do appreciate releases like this one. I'd also add
| Cloudflare to my list of "good ones"; they've taken a hard
| stance against charging for bandwidth, and I think that
| single decision had controlled a ton of the incremental costs
| we see from their newer higher-level product offerings like
| Workers.
| satvikpendem wrote:
| I've been using Coolify on a Hetzner VPS, it works great,
| it's like an open source Heroku that works through Docker and
| Compose.
| asmor wrote:
| I had a look at it and it seemed interesting, but then I
| spotted the `-v /var/run/docker.sock:/var/run/docker.sock`.
| popcorncowboy wrote:
| In case anyone's wondering, that gives the container root
| level access to the host's Docker daemon. A big potential
| security hole.
| asmor wrote:
| It's also just generally wrong to build a scheduler on
| top of the docker API. We have CRI for a reason, because
| everyone knows Docker is not going to be around forever.
| Certainly not the company. Maybe dockerd.
| davnicwil wrote:
| > it's kind of a funny return to where I started ~20 years or
| so ago with web development
|
| It's a journey I've been going on too.
|
| All the new platforms and paradigms that have emerged have
| had an initial shallow aura of helpfulness that has drawn me
| in, but almost exclusively when digging in I've realised that
| they create more issues than they solve, and/or introduce
| limitations that aren't worth it and force me to write janky,
| overly complicated code to work around that isn't
| comprehensible even a few weeks hence.
|
| Maybe the most notable exception to this is containers. But
| in a sense they're an abstraction over the very same VPS
| paradigm. So that makes sense. It's not something new or
| different, just the same thing but with some advantages (and
| disadvantages too, obviously).
| r3trohack3r wrote:
| I've been using Cloudflare workers for a while now and I have
| to disagree.
|
| There are entire classes of problems I no longer worry about
| with Workers and can just focus on building. My search history
| is a reflection of that. I'm no longer looking up "how do I put
| this thing in a Jails or container to limit exposure?" "how do
| I properly secure an SSH server?" "what is the magic
| incantation in my NGinx configuration to get an A+ SSL rating?"
|
| I also spend less time thinking about ongoing maintenance,
| automating rotation of SSL certs, keeping system packages up to
| date, doing a dist-upgrade every few years, maintaining
| Terraform files to rebootstrap a server from scratch, thinking
| about hot/cold redundancy, etc.
|
| With (some) serverless providers an absolutely massive slice of
| the responsibility of building a web application is pushed
| across the API and vendor boundary and is someone else's
| responsibility.
|
| For me at least, this is huge. I have a handful of clients that
| don't have any full time engineering staff, and being able to
| push the cost of ongoing maintenance down is the only thing
| that allows them to afford building a custom application.
| samuelstros wrote:
| I updated my post. I meant with "deploy as VPS" "deploy as a
| (virtual private) server with a service like render, heroku".
|
| I agree the sys admin stuff, no thanks. the appeal of
| "serverless edge", at least to me, is ease of deployment.
| but, that ease of deployment is tooling / git integration
| rather than the underlying architecture.
|
| the benefit of "your functions are globally distributed" has
| yet to appeal to me. for large ecommerce maybe. but then
| again, just deploy your servers in a distributed fashion
| which is "easy" if no state persistent is involved and
| tooling like fly.io is emerging.
| davnicwil wrote:
| to be honest I think much of this is also solved by
| thinking of VPS as "docker compose on a VPS" (or whatever
| container tech you want to use to abstract away the bare-
| metal sysadmin stuff).
|
| I honestly think with containers there is much less need
| for stuff like render and heroku, even more so if you use
| SQLite and remove the hosted database complexity.
|
| In fact in many ways it's even better - for instance the
| ability to run locally with an exact bit-for-bit production
| environment. Can't really do that with a PaaS.
| supriyo-biswas wrote:
| I'm afraid you're trying to make system administration look
| much harder than it actually is. As an example, adding good
| defaults to your nginx config is automated by certbot, or you
| could use caddy. You could run your apps statelessly by
| containerizing your applications or by simply writing Ansible
| playbooks and then not have to worry about upgrades - you
| simply deploy the application on the new server and spin down
| the old one.
| jonasb wrote:
| Very interesting!
|
| If I need to do more than one query to the database in series, my
| intuition is that it would be faster to make those calls in the
| same region as the database, rather than at the edge. It seems to
| be true using Vercel's playground[1] (towards Supabase).
|
| Any guidance for Supabase based apps? Is it possible to run my
| functions close to the database?
|
| [1] https://edge-data-latency.vercel.app/
| kiwicopple wrote:
| for when it really matters, then you should just use a Postgres
| Function. That will be an order of magnitude faster than
| anything you do to match the region.
|
| Supabase has auto-generated APIs (using PostgREST), so you can
| execute a Postgres Functions like this: const
| { data, error } = await supabase.rpc('echo', { hello: 'world'
| })
| Mortiffer wrote:
| does any one have good practical experience running Supabase
| locally? Its against their business model to have this run well
| so I'm a bit scared of the growing lock-in.
|
| (P.S. if Supabase is listening some customers like myself would
| be willing to pay a significant amount for support in a
| kubernetes/docker deployment running on our servers. We currently
| pay $50k - $100k simply for enterprise support contracts for each
| Cloudera, kafka, Kong, Flink... Not your target customer group so
| would be silly to add thoughts out laud )
| timnpalmer wrote:
| Hey there - Tim here from Supabase! We have some options to
| explore here so probably best to connect on a call to get a
| better understanding of your project and how we can best align
| to help! Can you send me an email on tim@supabase.io and we can
| tee up a time? Cheers, Tim
| sonjaqql wrote:
| Yes! `supabase init` and `supabase start` gets most of the way
| there! Customizing the ports in `supabase/config.toml` makes
| having multiple supabase instances running easy. This works
| great for all the Postgres, auth, and storage things, as well
| as real-time functionality. My engineers have a single
| package.json script to get everything up and running.
|
| I work at an agency, and the dev teams run supabase locally. We
| use Prisma for migrations and maintaining our SQL functions and
| storage configurations. `supabase stop --backup` is our friend.
|
| Not being able to run multiple edge functions at a time kept us
| leaning into Cloud Run and Cloudflare. I'm excited about
| today's announcement.
| bryanrasmussen wrote:
| Is there something about Deno that makes Edge functions good to
| be based on it - Netlify also has its Edge functions in Deno
| https://docs.netlify.com/edge-functions/overview/ maybe just
| coincidence, but seen two edge functions in Deno implementations
| in the last hour so makes me wonder.
| inian wrote:
| One reason is that Deno can run on v8 isolates which start up
| really quickly. This makes the deploys near instantaneous and
| helps with cold start time too. The DX with Deno is pretty neat
| since it comes in bundled with a test runner, doc generator,
| linter, bundler, etc.
| inian wrote:
| Hi, Supabase engineer here.
|
| This is a webserver built on the Deno runtime. Deno makes it easy
| to build a custom JavaScript runtime [1]. I am excited about
| extending this runtime to integrate it better with the rest of
| the Supabase stack. For example, we can modify the Deno
| filesystem API to read and write files to Supabase Storage
| instead.
|
| [1] https://deno.com/blog/roll-your-own-javascript-runtime
| rubenfiszel wrote:
| Thank you for open-sourcing especially under MIT license. I am
| digging through the codebase and finding a lot of interesting
| things.
|
| I am building another open-source project that is also a self-
| hosted deno runtime written in Rust, Windmill [1], where we
| enable to build all of your internal tool and infra (endpoints,
| workflows, apps) based on scripts (deno, but also python, go,
| bash). Instead of running one http server continuously for your
| function, we run it on demand which has its own set of
| challenges.
|
| We are doing something pretty naive right now: we create a fork
| and call deno run [2]. It's decently efficient (25ms for a naive
| script e2e). We are familiar with deno_core and use it in other
| places to run javascript directly, but for typescript, deno
| didn't expose directly the root entrypoint as a lib so we had to
| fork it [3] and are now gonna be able to do the transpiling to js
| AOT and save the fork for sub 5ms script execution.
|
| We also want to make some functions togglable as high-performance
| endpoints and for those we would want them to be spawned as http
| servers to save the cold start. I'm gonna investigate thoroughly
| the codebase, and thank you very much for having shared it.
|
| [1]: https://github.com/windmill-labs/windmill
|
| [2]: https://github.com/windmill-
| labs/windmill/blob/main/backend/...
|
| [3]: https://crates.io/crates/deno_cli_lib_windmill
| kiwicopple wrote:
| Let us know if you have any questions - our engineers are
| always happy to help other open source communities.
| 999900000999 wrote:
| Do you have feature parity with Firebase. The main thing I love
| is getting auth up and running.
|
| The Flutter integration is also top notch.
| kangmingtay wrote:
| Hi, Supabase Auth Engineer here. We are very close to feature
| parity with Firebase Auth. Off the top of my head, the 2
| features we're missing right now is anonymous authentication
| and multi-tenancy.
|
| We're also gonna be launching something auth-related this week
| too so stay tuned!
| spiderice wrote:
| Supabase Auth is very similar to Firebase Auth. Both are easy
| to setup with just a couple lines of code. The advantage, imo,
| is that Supabase just stores your user data in a regular
| Postgres database so you can then set up relations with other
| tables.
|
| I haven't used Flutter, but it looks like Supabase has a
| flutter library and documentation on how to use it:
| https://supabase.com/docs/guides/getting-started/tutorials/w...
|
| I used Firebase for a long time, and Supabase more recently. I
| have no desire to go back to Firebase. No longer having to
| obsess over read/write count (like you do with Firestore), and
| being able to leverage full SQL when needed, is a game changer.
| guykdm wrote:
| Request pre-processing using JavaScript is amazing! Will I be
| able to deploy an Astro app on supabase edge functions? I'm
| building a multi-tenant B2B2C product on supabase that's deployed
| on a customer's sub-domain, so writing reverse proxy logic in js
| would be a boon.
| inian wrote:
| We currently block HTML responses on Functions and Storage, but
| we are considering relaxing that limitation, so that you can
| host static sites on our Storage. And allowing user-defined
| functions running on every request to Storage in the edge
| runtime would get you the reverse proxy logic you are looking
| for.
| qbasic_forever wrote:
| How is the real world WASM story for typical server side
| languages like python, ruby, etc. these days? Last I looked at it
| WASM seemed to have a lot of warts and complications (and limited
| real world language support) vs. just spinning up a native
| process in a container. Can you go from for example python flask
| API source file to serving requests in WASM with minimal fuss or
| loss of functionality vs. native CPython?
| MuffinFlavored wrote:
| Is this bad for Cloudflare? aka this is competition to their
| "Workers" product?
| kiwicopple wrote:
| This can definitely be used as an alternative to Workers if you
| prefer self-hosting.
|
| You can also use Deno Deploy (https://deno.com/deploy), if you
| want a Workers alternative but don't want to self-host
| MuffinFlavored wrote:
| Any thoughts on implementing really "enterprise" languages
| like Java or C# so you could attract "the big boys"
| (corporations)?
|
| I know the corporations I work at are very anti-node.js and
| very pro-C# and everything needs to be approved by a tech
| committee. I don't think we could get Supabase approved (and
| instead we fork millions a month to Azure instead).
|
| Just a bit of feedback. I'm not a fan of C# or Java at all
| these days given how good Rust, node.js/Typescript/Deno have
| become. I just now work for 40,000+ person companies where I
| know this would be a non-starter unless you were super lucky
| to get all approvals aligned and be on one of the "cool"
| team.
|
| Maybe not the pivot/user feedback that aligns with your
| goals. :D
| kiwicopple wrote:
| We won't add support for other languages in our Edge
| Functions (beyond WASM support), but we are adding native
| support for other languages in our client libraries. For
| example, we already have C# support:
| https://supabase.com/docs/reference/csharp/introduction
|
| The idea is that you'd just use the client libraries in
| your favourite framework.
| inian wrote:
| We are planning to focus on the Deno and WASM ecosystem. If
| C# complies to WASM, we would be able to run it, but have a
| lot of work to do to make this seamless.
| pier25 wrote:
| It's as bad as Deno Deploy has always been (used by Netlify
| edge functions, Supabase, and others).
|
| To me CF Workers are more about interacting with the CF CDN,
| doing lightweight HTTP stuff, etc. I would never use Workers to
| build a full server application. Their custom runtime locks you
| in, it's extremely barebones, and obviously almost no NPM
| modules are compatible.
|
| They are working on Node compat which will probably help but I
| feel CF hasn't been investing enough into their cloud products
| (Workers, Pages, etc). DX is still hit and miss and progress
| overall feels glacial.
| MuffinFlavored wrote:
| Very well said. What would you say CF has been investing in
| instead?
| pier25 wrote:
| My superficial impression is they've been investing more in
| their networking services for enterprise customers but
| don't take my word for it. I don't pay much attention to
| their announcement weeks.
| what-no-tests wrote:
| Memes
| kiwicopple wrote:
| hey hn, supabase ceo here
|
| This is a webserver for Deno. It is MIT licensed, written in
| Rust, and based on the latest Deno Runtime (1.32+). It can serve
| TypeScript, JavaScript, and WASM functions.
|
| This one is important for local development and self-hosting. For
| local development, it ensures there is parity between development
| and production. For self-hosting, it means you can deploy and
| manage your Deno Functions on your own hardware. We have provided
| a Demo repository for deploying to Fly.io [1]. The runtime is not
| production-ready, but it is in a usable state. Note that we still
| use Deno Deploy at Supabase, and strongly recommend it for your
| own Deno functions.
|
| In the medium-term, this will reduce our tech-stack by 1 service.
| We'll remove Kong (a reverse proxy) and replace it with the Deno
| runtime. I'm excited about some other possibilities that this
| provides for self-hosting - one that we talked about was the
| ability to bundle a SQLite file with your functions, for a fully-
| contained and globally deployed webserver.
|
| The team will be around if you have any questions
|
| [1] Deploy on Fly: https://github.com/supabase/self-hosted-edge-
| functions-demo
| samuba wrote:
| Interesting! Do you have an idea of what it would mean
| performance/latency wise to replace kong with this?
| laktek wrote:
| We are yet to complete our Kong replacement. Once we do that,
| we'll probably publish another blog post with performance
| benchmarks.
| trevor-e wrote:
| Is Supabase targeted towards webdev "apps" or mobile "apps"? As
| a mobile dev I got excited to check out a Firebase + serverless
| alternative, but the docs seem very targeted towards webdevs
| and non-native apps.
|
| I see there's a 1.0 Swift library that's available, would love
| if someone can chime in with their experience using that in an
| iOS app.
| MrOwnPut wrote:
| They seem to have Flutter support but the lack of React
| Native support is non starter for me.
| paradaux wrote:
| I'm working on several RN + Supabase projects and it just
| works !
|
| There were a few kinks initially, like URL polyfil being
| missing from RN and the need for AsyncStorage alongside
| supabase.js but they've all been rectified by the team or
| made more clear using their Expo instructions in the docs
| -- Although maybe it'd be clearer for people that the expo
| guide is for RN? People who haven't started using RN might
| not know the connection?
|
| It's such a pleasant stack, we're experimenting currently
| with edge functions in place of an API in certain places,
| so far it's just to use Cloudflare Turnstile to insert
| contact form records into a database, but it's super
| trivial.
|
| Excited for the future of edge functions!
| kiwicopple wrote:
| Actually React Native is supported with the JS libs. While
| we don't have React Native docs, here is one for Expo which
| should be easy enough to convert:
| https://supabase.com/docs/guides/getting-
| started/tutorials/w...
|
| We also support swift:
| https://supabase.com/docs/reference/swift/introduction
|
| One more thing - we will have some more announcements for
| mobile (specifically auth) tomorrow.
| MrOwnPut wrote:
| I see, awesome. Thanks for the clarification!
| ovao wrote:
| Congrats on the launch! I've been so underwhelmed with Lambda's
| lack of forward progress lately and have been wanting to play
| around a bit with V8 isolates. This looks like a super-easy way
| to get a runtime spun up and handling requests on AWS.
| helsontaveras18 wrote:
| Open question: what are the benefits of replacing Lambda with
| this new service, if you're not using any other Supabase
| functionalities?
|
| Our Lambdas are currently written in Typescript and built
| with esbuild. We zip them and push to AWS.
| tychi wrote:
| Great work!
|
| I've been dabbling with deno for a couple years now, one of the
| most powerful features I'm excited about is BroadcastChannel[1]
| support, which works with --unstable in Deno Deploy.
|
| One of the challenges I've run into is debugging timeouts in
| deno deploy, so I'm curious--
|
| 1. is BroadcastChannel supported in supabase self-hosted edge
| functions? 2. is there more tooling available to supabase edge
| functions to debug than currently in deno deploy?
|
| [1]: https://deno.com/deploy/docs/runtime-broadcast-channel
|
| --- if curious of specifics, this is my work in progress proof
| of concept, exploring using pathnames for channels, to get
| anyone on the same url path connected across regions through
| sockets and broadcast channel:
| https://github.com/tylerchilds/kickstart/blob/869506c9dae1e1...
| laktek wrote:
| [Supabase engineer & author of the blog post here.]
|
| Thanks! Good Questions
|
| 1. We haven't enabled BroadcastChannel in the Edge Runtime.
| Mainly because we haven't found good use cases for it within
| Edge Functions (it does make sense as a way to subscribe
| within a browser client, but not sure how it fits with
| async/short-lived nature of Edge Functions). Curious about
| how you plan to use BroadcastChannel in Edge Functions?
|
| 2. As I've mentioned in the blog post Edge Runtime allows you
| to tweak the duration and memory available for an Edge
| Function (check the examples/main/index.ts in the repo too).
| Personally, I use this option to debug timeouts and memory
| issues on Edge Functions. We also plan to introduce better
| ways to profile your Edge Functions in the future.
| wdb wrote:
| Any details about the removing of Kong? What did you use it for
| and how will this help with removing it?
| inian wrote:
| We use Kong as our API Gateway, so it is responsible for
| authentication, rate limiting, routing, etc. By moving that
| to edge runtime, we simplify our stack since we already run a
| edge runtime container to run user functions.
|
| The other motivation for doing this is that it makes our API
| Gateway programmable with user defined functions. For
| example, you could implement custom transformations for
| storage or augment the Authorization header with custom
| claims before calling Postgrest.
| robbywashere_ wrote:
| What does deno give you over node? I am assuming by first
| impression there are some standard libraries in these functions
| which aren't available otherwise in node?
| benatkin wrote:
| How about WASM functions? One of Deno's selling points is
| sandboxing but WASM takes it to a new level it seems. I've been
| looking into Spin and also Dapr with WasmEdge. There is even
| QuickJS which does JavaScript.
| nilslice wrote:
| Would love to know what you're interested in doing.. we make
| Extism[0] which allows you to more or less ignore the lack of a
| "standard library" for something like V8 wasm environments..
| Spin definitely makes it easier to compile high-level source
| code & have done great work on their SDKs to provide these
| "standard lib" elements. maybe Extism is useful, but if not
| please feel free to drop in our Discord[1] and chat w/ the
| team.
|
| [0]: https://github.com/extism/extism [1]:
| https://discord.gg/cx3usBCWnc
| laktek wrote:
| [Supabase engineer & author of the blog post]
|
| You can already use WASM modules within Edge Functions. We have
| an example on using WASM modules to generate OpenGraph images -
| https://github.com/supabase/supabase/tree/master/examples/ed...
|
| We are also exploring ways to create functions in WASM-
| supported languages and run them directly on Edge Runtime. We
| expect this would be easier WasmGC[0] is shipped and Deno's
| WASI support improves.
|
| [0] https://chromestatus.com/feature/6062715726462976
| benatkin wrote:
| Hmm, seems like an attempt to check the box prematurely.
|
| Users would manually have to give it access to all the APIs.
| kiwicopple wrote:
| This is the third big release this week (along with a Postgres
| Pooler and a Logging Server).
|
| If you're wondering why there are so many, we generally "build
| for three months" then do all of our big product announcements in
| a "Launch Week". We're 2 days into this Launch Week so there will
| be a few more releases to come.
| drecoe wrote:
| HIPAA support this week? :)
| kiwicopple wrote:
| We got SOC2 Type 2 last week, HIPAA is next.
|
| We won't do much of an announcement about SOC2, so you can
| consider this comment the "official announcement" :)
| louislang wrote:
| Having been through the pain of SOC2 Type 2, I'll consider
| this a big announcement as well!
| [deleted]
| robertlagrant wrote:
| These all look really interesting. How do you pick what to make
| next?
| kiwicopple wrote:
| Usually the teams know what they need to build based on user
| feedback (which we get a lot of).
|
| We don't have Product Managers, the developers are expected
| to be very product-focused and user-facing. After every
| launch week we ask them what they want to build and then they
| get to work.
| codetrotter wrote:
| That sounds like heaven. And you guys are using Rust!
| That's like, double heaven!
|
| Are you guys hiring ;)
| kiwicopple wrote:
| we hire very slowly: when we have a problem to solve and
| nobody is owning the problem in the current team, we
| write a job spec specifically for this role and hire
| someone.
|
| At the moment we don't have any Rust jobs, but we always
| you can keep an eye on supabase.com/careers or follow us
| on twitter to keep updated
| mahmoudimus wrote:
| Hi! Congratulations on the launch. I'm a big fan of what
| you folks are doing over there and I genuinely love your
| product.
|
| Would love to keep in touch to see when the changes to this
| will happen. Also speaking as a ceo & founder, my natural
| inclination is to keep that culture going, small and avoid
| hiring a PM as long as possible. As I reflect on my
| operating time, I wonder if it was a mistake not to find
| the right Product Manager (sic) early so that they can be
| inoculated with the culture as we grow. My estimation is
| that the ramp time for this would be at least 6 months (a
| year?) to have that future product manager operate with the
| same founding ethos.
|
| Lmk if you're open to chatting about it. I'm honestly super
| curious.
| kiwicopple wrote:
| > _wonder if it was a mistake not to find the right
| Product Manager (sic) early so that they can be
| inoculated with the culture as we grow._
|
| That's an interesting thought. We do have some techies
| "acting" as PMs across the team, but i can see how we
| might one a dedicated person at some point.
|
| always open to chatting to other founders - feel free to
| reach out.
| netcraft wrote:
| I can't seem to find info about a postgres pooler release this
| week, where am I missing it?
|
| Edit: never fails, you ask a question and then you immediately
| find it. https://news.ycombinator.com/item?id=35501718
___________________________________________________________________
(page generated 2023-04-11 23:00 UTC)