wrappers VS pgsql-http

I used one of their open source work in a project: https://github.com/supabase/wrappers

It’s appreciated since SaaS on AWS is a no-no in my field.

I’m currently playing with PostgreSQL, foreign data wrappers, and pgrx rust extensions. My development experience has been surprisingly smooth and enjoyable.

My main issue is that joins will be processed locally, so all the foreign data will be fetched before the join happens. But otherwise basic CRUD is easy.

https://wiki.postgresql.org/wiki/Foreign_data_wrappers

https://github.com/pgcentralfoundation/pgrx

https://github.com/supabase/wrappers

However, considering the emergence of Supabase wrappers, it might be more beneficial to develop a walkthrough focused on creating Rust-based wrappers. This way, the community can start building a variety of useful wrappers (really plugins).

We're experimenting with including tables connected to external data sources using Supabase Wrappers https://github.com/supabase/wrappers as a way to link external APIs into the GraphQL schema but that work is in an early stage. That approach would be limited to the Stripe, Firebase and S3 for now though

This would be an ideal use case for a postgresql foreign data wrapper. See more here: https://github.com/supabase/wrappers/

> On a sidenote, is not the wrappers for Airtable, BigQuery and ClickHouse opensourced? Or why did they skip that column in the second table?

All of the wrappers are open source. You can see the source for the Airtable, BigQuery, and ClickHouse wrappers here https://github.com/supabase/wrappers/tree/5fac8afb62e6e8362b...

The `self-hosted` column is only missing from the "under development" wrappers in the blog post's table because those are not production ready and shouldn't be self hosted (yet).

I don’t understand the question https://github.com/pramsey/pgsql-http

I am trying to use the supabase http rest client extension to fetch data from an external API. Following the supabase docs and the GitHub repo readme, I have not been able to successfully make a request that requires auth, specifically an API key in the request header with key x-api-key.

- Hasura Remote Schema (https://hasura.io/blog/tagged/remote-schemas/)

If you want more control over the web API and you were going to fetch the data within your Python back-end and process it there, for some use-cases (not all, but some), there are options:

- pg_http (https://github.com/pramsey/pgsql-http)

Life is about trade-offs. Doing the work in SQL is not without its drawbacks, but it's also not without its benefits, and that's true for doing the work in a general-purpose language as well. Whatever the drawbacks of doing it in SQL, one of the benefits has got to be eliminating the impedance mismatch (for people who regard that mismatch as a problem, and the OP seems to be one such person). What I claim is that doing the work directly in the database shouldn't be ruled out in general (the specifics of a given use-case may rule it out in particular) any more the the other common patterns (API hand-written in Python, for instance) shouldn't be ruled out in general.

You could e.g. use the trigger to call http api using e.g. https://github.com/pramsey/pgsql-http

I do this all the time just with Postgres functions. Just turn on the following extensions: http (https://github.com/pramsey/pgsql-http) pg_cron (https://github.com/citusdata/pg\_cron)