6 ms·

Seems relevant. https://twitter.com/philsturgeon/status/544965192883261441 https://twitter.com/philsturgeon/status/544965192883261441

by philstu 12y ago

michaelchisari 12y ago
I think most people here would prefer if your link had a better explanation/defense.
- curiously 12y ago
  PHP seems to attract the bottom of the barrel "brogrammer" types. Kayne West of PHP. That says it all.
  - philstu 12y ago
    I'm far more than the typical user. Oh and I know Go, so I must be super intelligent, because only super intelligent people use Go.
  - dang 12y ago
    "Please avoid introducing classic flamewar topics unless you have something genuinely new to say about them." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
  - steve-rodrigue 12y ago
    PHP is just a tool that makes it very easy to create quick websites using logic directly in html. I totally agree that this is a bad practice and should be avoided. This is why it attracted a lot of script kiddies at its beginning. On the othr hand, according to Wikipedia ( http://en.wikipedia.org/wiki/Brogrammer http://en.wikipedia.org/wiki/Brogrammer ) a "brogrammer" is a social programmer, normally attracted in hacking jobs at startups. Therefore, I believe PHP doesn't attract "brogrammers" since most startups do not work with PHP anymore. I believe new languages attracts more "brogrammers" than PHP. PS: Please keep in mind that, nowadays, there are a lot of good programmers that write clean PHP code. Just have a look at the Symfony2 code source.
- grumblestumble 12y ago
  Perhaps the explanation is so self-evident that it seems redundant. The entire point of an API is to abstract away the underlying database schema.
  - Sean-Der 12y ago
    I have to disagree. The most painful APIs I have had to work with are ones that try to abstract things away, and fail. They usually create bad abstractions (don't full understand what they are trying to expose) or they don't expose enough and I waste time trying to extend them. There is no way to know what information clients will need in the future, so it is better to not try and guess. I have no problems with a chatty client. A good example of this is the Google APIs. Sure when you open up the godoc for the google-api-clients it seems needlessly verbose, but I have found the patterns sane and much better than making another layer of pointless abstraction.
    - steve-rodrigue 12y ago
      A good API is an API that abstract its database schema and expose designed Endpoints (Objects) to its clients. By exposing Objects instead of your schema, your API has less chance to be updated as frequently, since its internal data storage is separated from its public API. For the same reason, it is a bad practice to have multiple applications reading and writing data directly in your database. Building an Endpoint based API on top of your database and sharing this API across your clients is a better option. Building an API directly on top of a database schema also brings the problem of impedance mismatch in all your client's applications: http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch http://en.wikipedia.org/wiki/Object-relational_impedance_mis... The problems here have nothing to do with the fact that the API might be chatty.
      - joevandyk 12y ago
        Views are the mechanism this uses to separate the representation from the underlying data model. You don't expose your schema directly with this tool, you expose views that can stay the same when the data model changes.
- philstu 12y ago
  It truly blows my mind that any further explanation would be required. If you want a data store that exposes your database over HTTP then use on of the billion data stores that is designed to do that. None of those are meant to be a public API, and doing this is so incredibly wreckless and short sighted I could write at least a chapter in a book about it. Actually, I did write a chapter in a book about it. https://leanpub.com/build-apis-you-wont-hate https://leanpub.com/build-apis-you-wont-hate A RESTful API is about so many more things than just shoving a generic CRUD interface on top of your data schema.
  - michaelchisari 12y ago
    > A RESTful API is about so many more things than just shoving a generic CRUD interface on top of your data schema. Am I mistaken in thinking that this project offers much more control than shoving a generic CRUD interface on top of a data schema? Obviously, something like this would provide a great way to bootstrap a REST api for the basics you need. Sure, it may run into limits when more specificity is necessary, but that's the trap that all autogen frameworks run into.
  - joevandyk 12y ago
    You can use this for CRUD api's, and then move to something else when you need to. Clients won't care.
  - glibgil 12y ago
    API developer and authur who handcrafts via middleware (PHP) hates framework that automatically generates APIs from database features? Quelle f'ing surprise.
    - philstu 12y ago
      A developer who has been invited into the USA twice because of his skills at building complex APIs for complex companies suggests that automated solutions are a cancer on the API building industry? Quelle f'ing surprise.
      - deleted 12y ago
- steve-rodrigue 12y ago
  I also believe that creating a CRUD RESTful API directly on top of your database schema is a very bad idea because of the potential impedance mismatch. Normally, a REST API is formed of Endpoints (Objects), so this article should explain the problem fairly well: http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch http://en.wikipedia.org/wiki/Object-relational_impedance_mis...

Seems relevant. https://twitter.com/philsturgeon/status/544965192883261441 https://twitter.com/philsturgeon/status/544965192883261441

by philstu 12y ago

Seems relevant. https://twitter.com/philsturgeon/status/544965192883261441 https://twitter.com/philsturgeon/status/544965192883261441

michaelchisari 12y ago

I think most people here would prefer if your link had a better explanation/defense.

curiously 12y ago
PHP seems to attract the bottom of the barrel "brogrammer" types. Kayne West of PHP. That says it all.
- philstu 12y ago
  I'm far more than the typical user. Oh and I know Go, so I must be super intelligent, because only super intelligent people use Go.
- dang 12y ago
  "Please avoid introducing classic flamewar topics unless you have something genuinely new to say about them." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- steve-rodrigue 12y ago
  PHP is just a tool that makes it very easy to create quick websites using logic directly in html. I totally agree that this is a bad practice and should be avoided. This is why it attracted a lot of script kiddies at its beginning. On the othr hand, according to Wikipedia ( http://en.wikipedia.org/wiki/Brogrammer http://en.wikipedia.org/wiki/Brogrammer ) a "brogrammer" is a social programmer, normally attracted in hacking jobs at startups. Therefore, I believe PHP doesn't attract "brogrammers" since most startups do not work with PHP anymore. I believe new languages attracts more "brogrammers" than PHP. PS: Please keep in mind that, nowadays, there are a lot of good programmers that write clean PHP code. Just have a look at the Symfony2 code source.
grumblestumble 12y ago
Perhaps the explanation is so self-evident that it seems redundant. The entire point of an API is to abstract away the underlying database schema.
- Sean-Der 12y ago
  I have to disagree. The most painful APIs I have had to work with are ones that try to abstract things away, and fail. They usually create bad abstractions (don't full understand what they are trying to expose) or they don't expose enough and I waste time trying to extend them. There is no way to know what information clients will need in the future, so it is better to not try and guess. I have no problems with a chatty client. A good example of this is the Google APIs. Sure when you open up the godoc for the google-api-clients it seems needlessly verbose, but I have found the patterns sane and much better than making another layer of pointless abstraction.
  - steve-rodrigue 12y ago
    A good API is an API that abstract its database schema and expose designed Endpoints (Objects) to its clients. By exposing Objects instead of your schema, your API has less chance to be updated as frequently, since its internal data storage is separated from its public API. For the same reason, it is a bad practice to have multiple applications reading and writing data directly in your database. Building an Endpoint based API on top of your database and sharing this API across your clients is a better option. Building an API directly on top of a database schema also brings the problem of impedance mismatch in all your client's applications: http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch http://en.wikipedia.org/wiki/Object-relational_impedance_mis... The problems here have nothing to do with the fact that the API might be chatty.
    - joevandyk 12y ago
      Views are the mechanism this uses to separate the representation from the underlying data model. You don't expose your schema directly with this tool, you expose views that can stay the same when the data model changes.
philstu 12y ago
It truly blows my mind that any further explanation would be required. If you want a data store that exposes your database over HTTP then use on of the billion data stores that is designed to do that. None of those are meant to be a public API, and doing this is so incredibly wreckless and short sighted I could write at least a chapter in a book about it. Actually, I did write a chapter in a book about it. https://leanpub.com/build-apis-you-wont-hate https://leanpub.com/build-apis-you-wont-hate A RESTful API is about so many more things than just shoving a generic CRUD interface on top of your data schema.
- michaelchisari 12y ago
  > A RESTful API is about so many more things than just shoving a generic CRUD interface on top of your data schema. Am I mistaken in thinking that this project offers much more control than shoving a generic CRUD interface on top of a data schema? Obviously, something like this would provide a great way to bootstrap a REST api for the basics you need. Sure, it may run into limits when more specificity is necessary, but that's the trap that all autogen frameworks run into.
- joevandyk 12y ago
  You can use this for CRUD api's, and then move to something else when you need to. Clients won't care.
- glibgil 12y ago
  API developer and authur who handcrafts via middleware (PHP) hates framework that automatically generates APIs from database features? Quelle f'ing surprise.
  - philstu 12y ago
    A developer who has been invited into the USA twice because of his skills at building complex APIs for complex companies suggests that automated solutions are a cancer on the API building industry? Quelle f'ing surprise.
    - deleted 12y ago
steve-rodrigue 12y ago
I also believe that creating a CRUD RESTful API directly on top of your database schema is a very bad idea because of the potential impedance mismatch. Normally, a REST API is formed of Endpoints (Objects), so this article should explain the problem fairly well: http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch http://en.wikipedia.org/wiki/Object-relational_impedance_mis...