4 ms·

What about when changes are made to the schema, wont the API just be changed in that case? Wont this lock you in with very hard coupling between your db schema

by bni 11y ago

What about when changes are made to the schema, wont the API just be changed in that case? Wont this lock you in with very hard coupling between your db schema and public REST API?

glogla 11y ago
You can do that using SQL views. That means you can provide consistent api of your choosing no matter how the original tables look like. Postgrest docs also describe how you should use this feature to version you API.
- jacques_chester 11y ago
  And, in fact, it's best practice to never expose your physical schema to applications.
  - spacemanmatt 11y ago
    So true. A good remote facade decouples the usage interface from the physical schema, giving you quite a bit of flexibility.
- kelseydh 11y ago
  Implementing SQL views is not exactly trivial if you are operating under an existing Ruby on Rails app. I suspect most RoR developers don't use SQL views unless they absolutely need to for a certain query that's heavy on performance. As a result, the coupling to the schema does seem to be concerning as moving everything to SQL views appears to be a high amount of overhead if you're already successfully relying on an ORM.
  - glogla 11y ago
    You're right. It kind of depends on whether you look on the DB as a datastore, that is the DB and the Rails app are the same "system" with regards to other parts of the infrastructure, or of the database is system by itself, that provides services to other systems. It depends on what the DB does, really - eshop app + db might be the first one, while operational data warehouse would be the second. Usually you end up with something in the middle - like the eshop app, that provides views with summarized data to be ETLed to reporting.
  - spacemanmatt 11y ago
    When I did PG performance work as an application-DBA, Rails and its usage by users fairly unfamiliar with SQL was a constant source of aggravation.
  - dragonwriter 11y ago
    > Implementing SQL views is not exactly trivial if you are operating under an existing Ruby on Rails app. From the applications side, it should be completely transparent to replace base tables with views. From the database side, assuming you keep the views and the base tables in the same schema, for the initial transition, you just need to rename the base tables, and then create views with the names of the original tables referencing them; they'll be simple views, and so, in postgres, automatically updatable, so you won't even need to explicitly define update logic.
cies 11y ago
You could always write a custom API using any one of the many libraries/frameworks fit to do so. If you want to use Haskell (easy binary deploys, fast and strict type safety for cheaper maintenance, less bugs, easy refactoring) you could have a look at servant[1]. [1]: https://github.com/haskell-servant/servant https://github.com/haskell-servant/servant

by bni 11y ago

What about when changes are made to the schema, wont the API just be changed in that case? Wont this lock you in with very hard coupling between your db schema and public REST API?

glogla 11y ago

You can do that using SQL views. That means you can provide consistent api of your choosing no matter how the original tables look like. Postgrest docs also describe how you should use this feature to version you API.

jacques_chester 11y ago
And, in fact, it's best practice to never expose your physical schema to applications.
- spacemanmatt 11y ago
  So true. A good remote facade decouples the usage interface from the physical schema, giving you quite a bit of flexibility.
kelseydh 11y ago
Implementing SQL views is not exactly trivial if you are operating under an existing Ruby on Rails app. I suspect most RoR developers don't use SQL views unless they absolutely need to for a certain query that's heavy on performance. As a result, the coupling to the schema does seem to be concerning as moving everything to SQL views appears to be a high amount of overhead if you're already successfully relying on an ORM.
- glogla 11y ago
  You're right. It kind of depends on whether you look on the DB as a datastore, that is the DB and the Rails app are the same "system" with regards to other parts of the infrastructure, or of the database is system by itself, that provides services to other systems. It depends on what the DB does, really - eshop app + db might be the first one, while operational data warehouse would be the second. Usually you end up with something in the middle - like the eshop app, that provides views with summarized data to be ETLed to reporting.
- spacemanmatt 11y ago
  When I did PG performance work as an application-DBA, Rails and its usage by users fairly unfamiliar with SQL was a constant source of aggravation.
- dragonwriter 11y ago
  > Implementing SQL views is not exactly trivial if you are operating under an existing Ruby on Rails app. From the applications side, it should be completely transparent to replace base tables with views. From the database side, assuming you keep the views and the base tables in the same schema, for the initial transition, you just need to rename the base tables, and then create views with the names of the original tables referencing them; they'll be simple views, and so, in postgres, automatically updatable, so you won't even need to explicitly define update logic.

cies 11y ago

You could always write a custom API using any one of the many libraries/frameworks fit to do so. If you want to use Haskell (easy binary deploys, fast and strict type safety for cheaper maintenance, less bugs, easy refactoring) you could have a look at servant[1]. [1]: https://github.com/haskell-servant/servant https://github.com/haskell-servant/servant