4 ms·
> The title does not reveal that the suggestion applies only to Postgres. I don't think the OP intends the suggestion to apply only to Postgres: > The name-gi
by deathanatos 2y ago
> The title does not reveal that the suggestion applies only to Postgres.
I don't think the OP intends the suggestion to apply only to Postgres:
> The name-giving PostgreSQL database is often already available and in systems where it is not, *it can be easily introduced with minimal effort.*
… i.e., don't have PG? Not a problem, just introduce it into your architecture! (/s, from me, but I think the OP is serious.)
> It is a bad idea to tie your architecture to a specific technology.
But I agree. These sort of "just keep wiring boxes together until it works" architectures cause so many headaches IME; so many pieces, each with its own failure modes and bugs. This is where I find the claim the OP makes,
> [this design, with PostgREST] is more flexible than one that is developed manually.
… dubious. No, the advantage of doing it in code I control is that I control t hat code, and if something needs to change, it can be. With wired-together-boxes-of-random-tooling like this, I have to pray my change fits into the whims of its config files.
- fzeindl 2y ago> … i.e., don't have PG? Not a problem, just introduce it into your architecture! (/s, from me, but I think the OP is serious.) I do think this is fairly simply for many companies. > But I agree. These sort of "just keep wiring boxes together until it works" architectures cause so many headaches IME; so many pieces, each with its own failure modes and bugs. This is where I find the claim the OP makes, I agree, but PostgREST is a very very simple box... > With wired-together-boxes-of-random-tooling like this, I have to pray my change fits into the whims of its config files. ... that needs almost no configuration except the database connection string.