Comments (4)
Thank you!
Here are my ignorant thoughts regarding what makes sense to me:
- private schema to hold internal representations
- api schema to hold rest interface (usually behind authentication)
- public schema to expose htmx functions (might or might not involve authentication)
from postgrest-docs.
In my projects, I have settled on 5 schemas:
- Two schemas to hold the data tables + business logic. The reason for two schemas is just the way I migrate the schema and not related to PostgREST (see PostgREST/postgrest#2999 (reply in thread)).
- Three schemas for the api layer:
exposed
: This schema is set fordb-schemas
. It's the only schema that is directly accessible via PostgREST and generates all the endpoints.extra
: This schema is set fordb-extra-search-path
. Putting objects here allows them to still be recognized by PostgREST - but they won't be exposed. For example, some internal views can live here, which you don't want exposed, but you still want PostgREST to be able to "see through them" to infer foreign key relationships on the base tables. Also computed columns, which need to be in the search path can live here, without accidentally exposing them as RPCs in the exposed schema. Finally, I also keep some domains over my internals types here, so that I never expose anydata.xxx
custom types to the api layer - those would show up in the OpenAPI output. Everything inextra
just shows up without schema prefix, because it's in the search path.api
: Internal helper functions, which PostgREST does not need to know about, but are still only relevant to the api layer and not to data or business logic layers.
I think those three schemas (four including data) should be represented in the "schema isolation" part, because they are needed to understand the differences between db-schemas
, db-extra-search-path
and purely internal schemas.
Maybe add another one for "extensions".
Each extension has it's own schema for me. That means it's immediately clear whenever I call a function from an extension, because it will always be prefixed with the extension's name.
from postgrest-docs.
One quick question I have is how to manage different versions of an API. Here is my assumption:
- Each API version gets it own schema, and therefore its own postgrest config and therefore its own port.
- Use nginx to map a port to a specific 443 url path (example: https://someurl.com/v1/sometable gets mapped to port 3000 vs https://someurl.com/v2/sometable gets mapped to port 3001)
I am including this thought in this thread because the assumption is that we can separate versions in different schemas.
I believe this works if you adopt the practice of where you allow the public/exposted versions of the schema to introduce breaking changes; however, you ensure the private schema does not break any actively supported public schema versions.
Curious to hear thoughts... Chuck
from postgrest-docs.
One quick question I have is how to manage different versions of an API.
I have not found a satisfying answer to that, yet.
I am including this thought in this thread because the assumption is that we can separate versions in different schemas.
Yes, absolutely. That makes a lot of sense.
I believe this works if you adopt the practice of where you allow the public/exposted versions of the schema to introduce breaking changes; however, you ensure the private schema does not break any actively supported public schema versions.
Right.
Also mentioned here: #69. A slightly different approach is discussed in PostgREST/postgrest#2166.
from postgrest-docs.
Related Issues (20)
- How-to for dynamic schemas with `pre-config` HOT 1
- serve image with img tag HOT 1
- Readthedocs will stop working on September 25 with the current config file HOT 1
- Docker crashing on M1 HOT 3
- limiting HTTP verbs in openapi response HOT 3
- Link to Installation from tutorial
- Move binary installation from tut0.rst to install.rst and add install options to tabs
- Library not loaded on Mac HOT 4
- Rename admin page name to Observability
- Deprecated "External JWT Generation" section using Auth0 Rules
- Chocolatey doesn't add `postgrest` to the PATH
- Drop all plain HTTP snippets in favor of `curl` commands HOT 1
- Missing entries in Preferences section HOT 1
- Show a more prominent version number
- Use the term "secret" instead of "password" in Tutorial 1
- Avoid Globbing in Curl examples HOT 2
- Move from tailwind to PicoCSS in HTMX how-to
- Expand on Schema Isolation HOT 2
- Recommend using `row_security = off` for starting up with RLS HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from postgrest-docs.