Functions megathread
# off-topicc
copple
11/25/2021, 7:29 AMFunctions megathread
copple
11/25/2021, 7:29 AM- What would you use supabase functions for?
- Is there a reason why you can't do it with the current Supabase services?
- Why would you choose Supabase for functions over existing functions providers (Vercel, Netlify, etc)
a
anothercoder
11/25/2021, 9:16 AMI prefer to code my custom validation and biz logic using familiar languages such as Python or Javascript/Typescript instead of plpgsql/postgresql programming.
anothercoder
11/25/2021, 9:19 AMSo the idea is to use Supabase Functions as my custom API provider.
c
chipilov
11/25/2021, 12:30 PMI second @User opinion, but I will be a bit more detailed about it:
chipilov
11/25/2021, 12:32 PMI would use Supabase functions as my API server. Why would I do that instead of simply deploying to directly to DigitalOcean/AWS/etc? The same reason why I use Supabase in the first place - avoid maintaining infrastructure as much as possible.
Assuming that Supabase functions would be as close as possible to a full Node.js environment, I would prefer it to other services (e.g. Firebase, etc) because:
(a) I don't use Next.js, so Vercel's solution seems like it's off the table (I guess I can still use Next.js ONLY for the API, haven't thought much about this option);
(b) because I prefer to keep all dev services as consolidated as possible (fewer accounts/config options to maintain). Hint: If Supabase offered hosting, that would be great 🙂
(c) because some services (like CloudFlare workers) do NOT provide a full Node.js environment and enforce some constraints on the libraries that can be used (for example, you cannot use libraries that use low-level libs like dns, although they are wokring on relaxing these constraints);
Finally, the reason why I would want to use Supabase functions instead of the current Supabase offering is:
- To enforce encapsulation and separation between the public API and the internal implementation, I avoid querying directly my internal tables and instead expose them via public views/functions/triggers;
- Currently, I use PL/pgSQL for these functions/triggers (and regular SQL for the views);
- While using PL/pgSQL for simple things works, the dev experience is quite a bit worse than what I am used to with TypeScript/Java because (a) debugging is much harder (b) the library ecosystem is less rich and (c) you miss on the benefits of intelli sense;
chipilov
11/25/2021, 12:34 PMFinally, I agree with the concerns that @User raised about the current state of serverless functions in general (https://discord.com/channels/839993398554656828/839993398554656831/912749378257698876) and so if Supabase functions suffer from the same drawbacks, it's likely that they will be a step up from PL/pgSQL but might still be easily outgrown for a bigger project
c
copple
11/25/2021, 12:42 PMthis is an awesome response, thanks @User 🙏
g
garyaustin
11/25/2021, 4:59 PMI use node.js functions to generate PDF files with PDFmake (I feel it is too heavy to load and run on the client) and sending out emails of user selected data. Right now my functions are still on firebase/google as I've not selected a new hosting platform yet. Since Supabase does not have a hosting option, I could find one that also has functions if I need to, but would still prefer functions be related to the database versus static hosting. Main goal is to reduce number of vendors as mentioned above for reliability and billing.
b
btelles
11/29/2021, 6:14 PMApologies for the late response (was with family and AFK the past week) I will admit I have not looked used functions at all (at Netlify, Vercel, Google Cloud, or otherwise). I've been working in the walled garden of Alphabet internal tools for 9 years and am considering Supabase as a side project.
If successful (and in order to scale the codebase) I'd like to easily support local, dev, staging, canary on prod, and prod environments/functions. I am not sure what the current story is for using or managing functions across those separate environments, but my gut says it would be non-trivial. So my goal would be to have an easy time doing the following:
(1) "start with a single function "binary" that I can deploy, to each environment
(2) add functions to that single binary such that it's easy for me to spin up and debug a local instance.
(3) evolve that binary into a more customized container that has fine-grained controls for scaling instances.
Having written the above, I suppose my main concern around using any cloud function solution is developer ergonomics, which is something I think you're trying to solve for. The supabase-cli is a great start, and it seems to me that adding another container to the mix with my own configuration, image, and functions would be a logical progression.