4 ms·

This is a super rude and arrogant thing to say. Have you considered, before dismissing a project with 1.2k commits, that it's not the 54 authors who worked on t

This is a super rude and arrogant thing to say. Have you considered, before dismissing a project with 1.2k commits, that it's not the 54 authors who worked on the project for three years who are missing something, but you who heard about it at most two hours ago?

Walkman 10y ago
I read the short introduction: "PostgREST is a standalone web server that turns your PostgreSQL database directly into a RESTful API. The structural constraints and permissions in the database determine the API endpoints and operations." If that shows what it does, than this project has no point at all, because REST is about a lot of things, but tying your database schema directly to your API is not one of them. One of the main point of REST is that it abstracts away the implementation detail of your project, so the client don't need to know anything about your database, they can use the things you expose them via the API. It's really sad that there are 54 developers who can't see this and made a useless thing instead of doing something great with their time. I'm never against somebody doing something, I usually really sorry that talent, time and hard work get wasted so much on unnecessary things.
- dexen 10y ago
  I have a little bit of experience with PostgreSQL. Coming from MySQL background, I was pleasantly surprised how much abstraction you can build into your PostgreSQL database itself. With just a few views and perhaps functions you can abstract away your actual data in clean and performant way, and thus enable use of such REST API without worrying too much about future schema change.
  - ruslan_talpa 10y ago
    You've just formulated one of the core concepts/techniques PostgREST relies on. You don't expose your core tables as an API, you expose views that extract data from your core tables, even if in the beginning those views are nothing more then "select * from some_table". As the api evolves, you are free to change the logic in those views without the need to touch your core tables
  - Walkman 10y ago
    That's actually a very good counter-argument against mine.
- scrollaway 10y ago
  Wow, unbelievable. I don't know in what world you think it's OK to call something useless just because you don't personally see its use, when faced with evidence that plenty of people in this thread alone do. I understand you're not a native speaker (neither am I), so I just want to make it very clear to you in case you don't realize it: Your original message, and this reply you just wrote, are both completely out of place and uncalled for. And incorrect on a technical level. This tool is exposing DB operations as an HTTP API. It wasn't written for you specifically, it was written to solve a particular scenario. One day, you'll encounter said scenario, and you won't even realize there's a tool out there to specifically solve it because you dismissed it as "useless". And instead of "doing something great with your time", you'll waste a few days/weeks reimplementing a poorer version of that wheel. I'm not affiliated with the project, I don't even use it, but I can still appreciate what it does. If you can't, that's fine, but don't shit on people's work no more knowledge about it than "reading the short introduction". Lest you want me to go through your Github profile and shit on your work based on how you name your repos, which would be just as productive.
  - Walkman 10y ago
    Ok the tone of my message might be out of line a little bit, but I find it important to make people aware of incorrect usage of principles/tools/framework/stuff. I would not have so much problem with this project if they would call it "API" instead of "REST API", because it would communicate the purpose much clearer. Also it would be a huge design mistake to use this on any serious project and probably not everybody will realize this.

Walkman 10y ago

I read the short introduction: "PostgREST is a standalone web server that turns your PostgreSQL database directly into a RESTful API. The structural constraints and permissions in the database determine the API endpoints and operations." If that shows what it does, than this project has no point at all, because REST is about a lot of things, but tying your database schema directly to your API is not one of them. One of the main point of REST is that it abstracts away the implementation detail of your project, so the client don't need to know anything about your database, they can use the things you expose them via the API. It's really sad that there are 54 developers who can't see this and made a useless thing instead of doing something great with their time. I'm never against somebody doing something, I usually really sorry that talent, time and hard work get wasted so much on unnecessary things.

dexen 10y ago
I have a little bit of experience with PostgreSQL. Coming from MySQL background, I was pleasantly surprised how much abstraction you can build into your PostgreSQL database itself. With just a few views and perhaps functions you can abstract away your actual data in clean and performant way, and thus enable use of such REST API without worrying too much about future schema change.
- ruslan_talpa 10y ago
  You've just formulated one of the core concepts/techniques PostgREST relies on. You don't expose your core tables as an API, you expose views that extract data from your core tables, even if in the beginning those views are nothing more then "select * from some_table". As the api evolves, you are free to change the logic in those views without the need to touch your core tables
- Walkman 10y ago
  That's actually a very good counter-argument against mine.
scrollaway 10y ago
Wow, unbelievable. I don't know in what world you think it's OK to call something useless just because you don't personally see its use, when faced with evidence that plenty of people in this thread alone do. I understand you're not a native speaker (neither am I), so I just want to make it very clear to you in case you don't realize it: Your original message, and this reply you just wrote, are both completely out of place and uncalled for. And incorrect on a technical level. This tool is exposing DB operations as an HTTP API. It wasn't written for you specifically, it was written to solve a particular scenario. One day, you'll encounter said scenario, and you won't even realize there's a tool out there to specifically solve it because you dismissed it as "useless". And instead of "doing something great with your time", you'll waste a few days/weeks reimplementing a poorer version of that wheel. I'm not affiliated with the project, I don't even use it, but I can still appreciate what it does. If you can't, that's fine, but don't shit on people's work no more knowledge about it than "reading the short introduction". Lest you want me to go through your Github profile and shit on your work based on how you name your repos, which would be just as productive.
- Walkman 10y ago
  Ok the tone of my message might be out of line a little bit, but I find it important to make people aware of incorrect usage of principles/tools/framework/stuff. I would not have so much problem with this project if they would call it "API" instead of "REST API", because it would communicate the purpose much clearer. Also it would be a huge design mistake to use this on any serious project and probably not everybody will realize this.