3 ms·

I’d really like to implement 2. but it’s quite difficult to make the switch to that approach when you already have a ton of tables.

by klysm 3y ago

tudorg 3y ago
If you are using Postgres, I think you can create a view for each table and put all the views in a schema, then you switch the app all at once by using `SET search_path TO`.
- claytonjy 3y ago
  You can, but I'd argue if your API schema is just 1-to-1 views for the underlying tables, you're not getting much value from this approach.
  - spott 3y ago
    Until you change the underlying tables, or the api schema. At which point you don’t need to change the other.
    - claytonjy 3y ago
      If your API view is a direct mapping of an underlying table (e.g. "SELECT *"), and you make a breaking change to that table, the view will also change and your application will break. What I've done instead is change the underlying table as needed, and ensure the view interface stays the same, by changing the view definition. This lets you refactor the low-level schema without breaking clients, and this migration can be done in a single transaction.
  - packetbeats 3y ago
    I was thinking of it as the starting point, then you evolve from there. Tbh, views are a bit of a leaky abstraction (for example when it comes to constraints) so adopting them gradually seems like a good idea.
claytonjy 3y ago
It is difficult, but it's possible, and I've had to take that hard road. At a high level it looked like 1. create API schema and start filling it out with useful stuff 2. one by one, migrate applications to the new schema. You'll find stuff missing from the API schema, and you'll add it, to support each application. Ideally you'll find commonality across applications, so you end up with a cohesive API schema and not a jumble of application-specific stuff. But this takes discipline! 3. as each application moves over, remove their access from the low-level schema(s)

I’d really like to implement 2. but it’s quite difficult to make the switch to that approach when you already have a ton of tables.

by klysm 3y ago

I’d really like to implement 2. but it’s quite difficult to make the switch to that approach when you already have a ton of tables.

tudorg 3y ago

If you are using Postgres, I think you can create a view for each table and put all the views in a schema, then you switch the app all at once by using `SET search_path TO`.

claytonjy 3y ago
You can, but I'd argue if your API schema is just 1-to-1 views for the underlying tables, you're not getting much value from this approach.
- spott 3y ago
  Until you change the underlying tables, or the api schema. At which point you don’t need to change the other.
  - claytonjy 3y ago
    If your API view is a direct mapping of an underlying table (e.g. "SELECT *"), and you make a breaking change to that table, the view will also change and your application will break. What I've done instead is change the underlying table as needed, and ensure the view interface stays the same, by changing the view definition. This lets you refactor the low-level schema without breaking clients, and this migration can be done in a single transaction.
- packetbeats 3y ago
  I was thinking of it as the starting point, then you evolve from there. Tbh, views are a bit of a leaky abstraction (for example when it comes to constraints) so adopting them gradually seems like a good idea.

claytonjy 3y ago

It is difficult, but it's possible, and I've had to take that hard road. At a high level it looked like 1. create API schema and start filling it out with useful stuff 2. one by one, migrate applications to the new schema. You'll find stuff missing from the API schema, and you'll add it, to support each application. Ideally you'll find commonality across applications, so you end up with a cohesive API schema and not a jumble of application-specific stuff. But this takes discipline! 3. as each application moves over, remove their access from the low-level schema(s)