search

supabase / postgrest-js

Isomorphic JavaScript client for PostgREST.
https://supabase.com
MIT License
1.06k stars 140 forks source link

Document or improve flexibility for absolute url requirement #245

Closed colearendt closed 1 year ago

colearendt commented 2 years ago

Feature request

Is your feature request related to a problem? Please describe.

To make deployment of my application "simpler," I have a proxy that listens on the same domain as the domain the UI is served from. (i.e. __api__/ gets sent to my PostgREST API, everything else goes to the frontend)

However, referring to this API in PostgrestClient with a relative path throws an error

vue.runtime.esm.js:1888 TypeError: Failed to construct 'URL': Invalid URL
    at new c (PostgrestQueryBuilder.js:6)
    at from (PostgrestClient.js:34)
    at na (actions.js:18)
    at m.<anonymous> (actions.js:364)
    at Array.<anonymous> (vuex.esm.js:847)
    at m.dispatch (vuex.esm.js:512)
    at m.dispatch (vuex.esm.js:402)
    at a.selectedAccount (Explorer.vue:182)
    at en.run (vue.runtime.esm.js:4568)
    at qi (vue.runtime.esm.js:4310)

From here: https://github.com/supabase/postgrest-js/blob/aa223b4569b5c08714bb1d029e8f780e19db2b09/src/lib/PostgrestQueryBuilder.ts#L14

Contrasting this with axios, for instance, which takes a relative URL just fine.

Describe the solution you'd like

It would be ideal to be a bit more flexible in how URLs are taken / used so that relative paths can be used

Describe alternatives you've considered

At a minimum, better documentation and logging on the requirements for url (even just documenting that it will get passed to new URL() would be helpful).

The solution/workaround is to generate the absolute URL reference. In my case:

window.location.protocol + "//" + window.location.hostname + ":" + window.location.port + PG_URL

This is much less than ideal because I have to track a separate URL for the PostgrestClient than for my other API client libraries (and the application is hosted at different schemes, potentially at different root paths, etc.).

Additional context

soedirgo commented 2 years ago

Yes, we should document that it's meant to accept absolute URLs. The fact that it uses WHATWG URL is an implementation detail - I don't think we should expose that (we previously used superagent).

The workaround is inconvenient, but I don't think it's worth adding the relative URL handling right now (unless maybe if WHATWG URL supports relative URL w/o base OOTB).