6 ms·

This is not a good idea at all. One of the main point of a REST API is to abstract away your internal data structures for the clients that makes sense. Also ref

This is not a good idea at all. One of the main point of a REST API is to abstract away your internal data structures for the clients that makes sense. Also refactoring and database migrations should NOT change the public API of any software, especially not a REST API. Now, when using something like this, even the most basic change will have a ripple effect on your whole infrastructure and break every client.

fulafel 6y ago
Depends on your use case. REST is about putting resources on the web. Sometimes it can be eg datasets backes by SQL tables. Views / stored procedures are recommended to provide APIs.
bausano_michael 6y ago
I can see how an API like this would be a great fit for some no code solution integration. Certainly bad idea in some situations, but let's not be too quick to judge the usefulness of the project.
- kissgyorgy 6y ago
  I'm not saying it cannot be useful at all, but most projects should not even consider using it.
kowlo 6y ago
After reading your comment I expected to see low to mediocre activity on their repository... however, 15.1k stars seems to indicate that many do think it's a good idea. I know GitHub stars are not a measure of whether something is a good idea or not - but why do you think so many have positively engaged with it?
- kissgyorgy 6y ago
  Lots of developers in general doesn't seem to understand the concept of a REST API. What are the benefits? Why are we doing this at all? How to do it properly? Most APIs are not REST, just some RPC-like APIs over HTTP. When you have a tool like this, it's just easier to use it and call it a day - without thinking too much or learning the concepts properly.
  - deleted 6y ago
    [deleted]
  - avinassh 6y ago
    > Most APIs are not REST, just some RPC-like APIs over HTTP. Can you elaborate this part? Does PostgREST does that? If not, any example of it
    - corytheboyd 6y ago
      I think the point is that many people in the wild conflate the term “REST API” with “arbitrary interaction over HTTP”. We’ve all seen examples, the one-off endpoint to fetch that little tertiary bit of data, that one-off POST to invalidate a cache. None of that is REST
    - abraae 6y ago
      To REST purists, APIs must use HATEOAS to be considered REST.
      - masklinn 6y ago
        "HATEOAS" is pretty much the only thing REST contains. "REST API" without HATEOAS has no meaning, it's just a stand-in for "good HTTP citizen" (if even that).
  - philwelch 6y ago
    REST isn’t an architecture for designing HTTP API’s; it’s an architecture for designing HTTP itself. https://twobithistory.org/2020/06/28/rest.html https://twobithistory.org/2020/06/28/rest.html
- joking 6y ago
  because actually is a great idea. maybe there are some cases where it’s not the best option, but many times it’s much better option than having to code a custom api code and you can invest that time in building more features instead of dealing with plumbing.
piaste 6y ago
From the docs: > It is recommended that you don’t expose tables on your API schema. Instead expose views and stored procedures which insulate the internal details from the outside world. This allows you to change the internals of your schema and maintain backwards compatibility. It also keeps your code easier to refactor, and provides a natural way to do API versioning. Which is, you'll notice, the same best practice used for decades by DBAs who need to serve multiple applications connecting to the same database. (Also, it's not exactly uncommon that a data store API would have a single client which you control - eg. a single webapp, an internal application... in which case you can go nuts with breaking changes.)
- systemvoltage 6y ago
  > Which is, you'll notice, the same best practice used for decades by DBAs who need to serve multiple applications connecting to the same database. Clearly, the Database's job contrary to what the name suggests is to not only stick data into it but also a bunch of business logic that's essentially untestable. No one needs domain models when you've got database tightly coupled with behavior and logic of your business. What could go wrong? The whole point of the API is that it is a repository for accessing the data from one or more databases, and packaging it up for the user to consume. It imports domain models which are totally isolated from the rest of the dependencies. The data doesn't even have to be in the database and can come from multiple sources such as S3 or whatever. It can consume data from the user and kick off various processes or insert into the database. It is a generic interface that does more than just CRUD in the DB.
  - mojzu 6y ago
    You can use pgTAP for postgres unit testing, with docker you can make the process pretty fast too. Id highly recommend looking into the features/extensions of postgres, there's a lot of great stuff that goes beyond just being a database which can save a lot of time and grief depending on the application. There is a risk of mixing storage/business logic, and you might end up being tied to postgres, but it's manageable using functions/views/schemas. And its also a really convenient place to do some business logic, as all your data is right there and available via a very expressive/extensible query language.
RedShift1 6y ago
I went all in on Postgraphile, directly tying API's to the database schema. And you know what? I LOVE IT. I love it so much I've migrated all other API's in the business over and got to delete thousands of lines of code that weren't necessary anymore. 99% of the time, REST API's are just glue code, mapping HTTP data to database data and vice versa. And for that 1% that you need, for example backwards compatbility with an earlier version of your API, there's computed columns, set returning functions, views, etc... You can keep your API compatible with older clients and keep moving your schema forward. But the most liberating thing about Postgraphile is that I get to spend a lot more time on the datastructures and frontend development. And it's really paying off, features can be delivered much faster, and you don't feel useless writing glue code all the time. This thing for real improved my life.
- deleted 6y ago
  [deleted]
- darkteflon 6y ago
  This was interesting, thanks. Have you also given Hasura a go? If not, would you? In your view are Hasura and Postgraphile reasonable substitutes? I’m not talking about non-hosted vs self-hosted, but rather capabilities, tooling, developer experience, etc. Would be great to hear your thoughts, thanks.
  - RedShift1 6y ago
    I've tried Hasura and it worked fine, but went with Postgraphile at the time because it was much easier to integrate into an already existing REST nodejs API. Plus I like the fact that Postgraphile leverages the database as much as possible, whilst Hasura implements things that could be done by the database. It's also much easier to extend Postgraphile, you just use Postgraphile as a library in your nodejs project and add as needed, allowing you to run entirely from one codebase. With Hasura you have to use schema stitching to extend its functionality, meaning you have to keep 2 pieces running instead of 1. When it comes to developer experience, Postgraphile is rather bare in its default form, you definitely want to add a bunch of plugins to make the resulting GraphQL side as powerful as you need it to be. Hasura is much more of a blackbox, you set it up and what you see is what you get. Postgraphile is much easier to mold into exactly what you want. In the end they are projects with semi-same goals but different approaches. I went with Postgraphile and I haven't regretted it one bit, but no reason you can't try both, they are easy to set up and get a lay of the land.
micimize 6y ago
I'm not sure about postgrest, but with postgraphile you can control field exposure and add getters/setters fairly granularly. Regardless, that's no reason to say it's "not a good idea at all." having a schema change ripple through the stack is just a trade-off, which is often even desirable. If engineers are shipping code to production with postgrest, and attributing it in part to their success, maybe reconsider the rigidity of your architectural thinking. https://paul.copplest.one/blog/nimbus-tech-2019-04.html#api-layer https://paul.copplest.one/blog/nimbus-tech-2019-04.html#api-...
neuromanser 6y ago
This is very shallow, unimaginative thinking. Of course you'll abstract away your internal data structures: just don't expose the base tables, and give access through a client-specific schema comprised of tailored views instead.
dragonwriter 6y ago
> This is not a good idea at all. It's an excellent idea. > One of the main point of a REST API is to abstract away your internal data structures for the clients that makes sense. One of the points of database views, which are much older than REST, is to abstract away your internal data structures behind facades that make sense for the clients. > Also refactoring and database migrations should NOT change the public API of any software, especially not a REST API. That's...inaccurate. Refactoring, including of the base storage layer shouldn't. The exposed schema of a database is an API, which is logically distinct from the base storage layer. Some designs may just expose base tables and handle mapping for the client outside of the database, but there's no fundamental reason it has to be that way. > Now, when using something like this, even the most basic change will have a ripple effect on your whole infrastructure and break every client. No, it won't. PostgREST exposes a single schema. There's no reason that schema should contain low-level implementation, just the views defining the public API.
- systemvoltage 6y ago
  > One of the points of database views, which are much older than REST, is to abstract away your internal data structures behind facades that make sense for the clients. It makes sense to put all the logic into DB views and ditch the domain models. Forget unit tests and functional tests against company's business logic - those are pretty obsolete concepts. We don't need robust software, we need quick and dirty ducktaped APIs. Who needs data validation?
  - dragonwriter 6y ago
    > It makes sense to put all the logic into DB views and ditch the domain models DB views are a mechanism for representing domain models just as much as classes in an OOP language are. > Forget unit tests and functional tests against company's business logic Implementing functionality in the DB changes how you implement and execute tests, but it doesn't prevent testing. If you are using a DB at all and don't understand how to test functionality implemented there, that's a problem, sure, but the correction to that problem isn't to just minimize the functionality in the database and continuing to fail to test it.
deleted 6y ago
[deleted]

fulafel 6y ago

Depends on your use case. REST is about putting resources on the web. Sometimes it can be eg datasets backes by SQL tables. Views / stored procedures are recommended to provide APIs.

bausano_michael 6y ago

I can see how an API like this would be a great fit for some no code solution integration. Certainly bad idea in some situations, but let's not be too quick to judge the usefulness of the project.

kissgyorgy 6y ago
I'm not saying it cannot be useful at all, but most projects should not even consider using it.

kowlo 6y ago

After reading your comment I expected to see low to mediocre activity on their repository... however, 15.1k stars seems to indicate that many do think it's a good idea. I know GitHub stars are not a measure of whether something is a good idea or not - but why do you think so many have positively engaged with it?

kissgyorgy 6y ago
Lots of developers in general doesn't seem to understand the concept of a REST API. What are the benefits? Why are we doing this at all? How to do it properly? Most APIs are not REST, just some RPC-like APIs over HTTP. When you have a tool like this, it's just easier to use it and call it a day - without thinking too much or learning the concepts properly.
- deleted 6y ago
  [deleted]
- avinassh 6y ago
  > Most APIs are not REST, just some RPC-like APIs over HTTP. Can you elaborate this part? Does PostgREST does that? If not, any example of it
  - corytheboyd 6y ago
    I think the point is that many people in the wild conflate the term “REST API” with “arbitrary interaction over HTTP”. We’ve all seen examples, the one-off endpoint to fetch that little tertiary bit of data, that one-off POST to invalidate a cache. None of that is REST
  - abraae 6y ago
    To REST purists, APIs must use HATEOAS to be considered REST.
    - masklinn 6y ago
      "HATEOAS" is pretty much the only thing REST contains. "REST API" without HATEOAS has no meaning, it's just a stand-in for "good HTTP citizen" (if even that).
- philwelch 6y ago
  REST isn’t an architecture for designing HTTP API’s; it’s an architecture for designing HTTP itself. https://twobithistory.org/2020/06/28/rest.html https://twobithistory.org/2020/06/28/rest.html
joking 6y ago
because actually is a great idea. maybe there are some cases where it’s not the best option, but many times it’s much better option than having to code a custom api code and you can invest that time in building more features instead of dealing with plumbing.

piaste 6y ago

From the docs: > It is recommended that you don’t expose tables on your API schema. Instead expose views and stored procedures which insulate the internal details from the outside world. This allows you to change the internals of your schema and maintain backwards compatibility. It also keeps your code easier to refactor, and provides a natural way to do API versioning. Which is, you'll notice, the same best practice used for decades by DBAs who need to serve multiple applications connecting to the same database. (Also, it's not exactly uncommon that a data store API would have a single client which you control - eg. a single webapp, an internal application... in which case you can go nuts with breaking changes.)

systemvoltage 6y ago
> Which is, you'll notice, the same best practice used for decades by DBAs who need to serve multiple applications connecting to the same database. Clearly, the Database's job contrary to what the name suggests is to not only stick data into it but also a bunch of business logic that's essentially untestable. No one needs domain models when you've got database tightly coupled with behavior and logic of your business. What could go wrong? The whole point of the API is that it is a repository for accessing the data from one or more databases, and packaging it up for the user to consume. It imports domain models which are totally isolated from the rest of the dependencies. The data doesn't even have to be in the database and can come from multiple sources such as S3 or whatever. It can consume data from the user and kick off various processes or insert into the database. It is a generic interface that does more than just CRUD in the DB.
- mojzu 6y ago
  You can use pgTAP for postgres unit testing, with docker you can make the process pretty fast too. Id highly recommend looking into the features/extensions of postgres, there's a lot of great stuff that goes beyond just being a database which can save a lot of time and grief depending on the application. There is a risk of mixing storage/business logic, and you might end up being tied to postgres, but it's manageable using functions/views/schemas. And its also a really convenient place to do some business logic, as all your data is right there and available via a very expressive/extensible query language.

RedShift1 6y ago

I went all in on Postgraphile, directly tying API's to the database schema. And you know what? I LOVE IT. I love it so much I've migrated all other API's in the business over and got to delete thousands of lines of code that weren't necessary anymore. 99% of the time, REST API's are just glue code, mapping HTTP data to database data and vice versa. And for that 1% that you need, for example backwards compatbility with an earlier version of your API, there's computed columns, set returning functions, views, etc... You can keep your API compatible with older clients and keep moving your schema forward. But the most liberating thing about Postgraphile is that I get to spend a lot more time on the datastructures and frontend development. And it's really paying off, features can be delivered much faster, and you don't feel useless writing glue code all the time. This thing for real improved my life.

deleted 6y ago
[deleted]
darkteflon 6y ago
This was interesting, thanks. Have you also given Hasura a go? If not, would you? In your view are Hasura and Postgraphile reasonable substitutes? I’m not talking about non-hosted vs self-hosted, but rather capabilities, tooling, developer experience, etc. Would be great to hear your thoughts, thanks.
- RedShift1 6y ago
  I've tried Hasura and it worked fine, but went with Postgraphile at the time because it was much easier to integrate into an already existing REST nodejs API. Plus I like the fact that Postgraphile leverages the database as much as possible, whilst Hasura implements things that could be done by the database. It's also much easier to extend Postgraphile, you just use Postgraphile as a library in your nodejs project and add as needed, allowing you to run entirely from one codebase. With Hasura you have to use schema stitching to extend its functionality, meaning you have to keep 2 pieces running instead of 1. When it comes to developer experience, Postgraphile is rather bare in its default form, you definitely want to add a bunch of plugins to make the resulting GraphQL side as powerful as you need it to be. Hasura is much more of a blackbox, you set it up and what you see is what you get. Postgraphile is much easier to mold into exactly what you want. In the end they are projects with semi-same goals but different approaches. I went with Postgraphile and I haven't regretted it one bit, but no reason you can't try both, they are easy to set up and get a lay of the land.

micimize 6y ago

I'm not sure about postgrest, but with postgraphile you can control field exposure and add getters/setters fairly granularly. Regardless, that's no reason to say it's "not a good idea at all." having a schema change ripple through the stack is just a trade-off, which is often even desirable. If engineers are shipping code to production with postgrest, and attributing it in part to their success, maybe reconsider the rigidity of your architectural thinking. https://paul.copplest.one/blog/nimbus-tech-2019-04.html#api-layer https://paul.copplest.one/blog/nimbus-tech-2019-04.html#api-...

neuromanser 6y ago

This is very shallow, unimaginative thinking. Of course you'll abstract away your internal data structures: just don't expose the base tables, and give access through a client-specific schema comprised of tailored views instead.

dragonwriter 6y ago

> This is not a good idea at all. It's an excellent idea. > One of the main point of a REST API is to abstract away your internal data structures for the clients that makes sense. One of the points of database views, which are much older than REST, is to abstract away your internal data structures behind facades that make sense for the clients. > Also refactoring and database migrations should NOT change the public API of any software, especially not a REST API. That's...inaccurate. Refactoring, including of the base storage layer shouldn't. The exposed schema of a database is an API, which is logically distinct from the base storage layer. Some designs may just expose base tables and handle mapping for the client outside of the database, but there's no fundamental reason it has to be that way. > Now, when using something like this, even the most basic change will have a ripple effect on your whole infrastructure and break every client. No, it won't. PostgREST exposes a single schema. There's no reason that schema should contain low-level implementation, just the views defining the public API.

systemvoltage 6y ago
> One of the points of database views, which are much older than REST, is to abstract away your internal data structures behind facades that make sense for the clients. It makes sense to put all the logic into DB views and ditch the domain models. Forget unit tests and functional tests against company's business logic - those are pretty obsolete concepts. We don't need robust software, we need quick and dirty ducktaped APIs. Who needs data validation?
- dragonwriter 6y ago
  > It makes sense to put all the logic into DB views and ditch the domain models DB views are a mechanism for representing domain models just as much as classes in an OOP language are. > Forget unit tests and functional tests against company's business logic Implementing functionality in the DB changes how you implement and execute tests, but it doesn't prevent testing. If you are using a DB at all and don't understand how to test functionality implemented there, that's a problem, sure, but the correction to that problem isn't to just minimize the functionality in the database and continuing to fail to test it.

deleted 6y ago

[deleted]