Many views are "auto updatable" in Postgres, meaning the db knows how to seamlessly pass updates down to the underlying relation. https://www.postgresql.org/docs/current/static/rules-views.h...

For more updates to more complicated views (such as some joins), you can use a trigger as also described in the linked docs above.

Your original comment said it's bad to couple your api with tables so I am agreeing with you, use views to decouple. for writes, you can use stored procedures for corner cases although most of the apps work with one model at a time, so auto-updatable views work most of the time. So if we take into account that most apps talk to one database, i have most of it covered with simple views since usually you have a 80/20 read/write split? I'll take that.

FDW are very elegant for reading data from other systems. If you can read from twitter https://github.com/umitanuki/twitter_fdw you can read from anything although I don't understand why you brought up microservices, this is one one of the microservices (that is talking to the db), it's not the thing trying to unite all microservices. You can have GraphQL on top of PostgREST just fine (https://subzero.cloud).