4 ms·

I'd love to see a jsonapi[1] interface to postgres. I'm mainly building ember apps at the moment and the rails layer is really just an interface straight onto t

by ollysb 12y ago

I'd love to see a jsonapi[1] interface to postgres. I'm mainly building ember apps at the moment and the rails layer is really just an interface straight onto the database(all the logic is client side). [1] http://jsonapi.org http://jsonapi.org

andrewstuart2 12y ago
That works fine as long as you never need security or robust application logic. Somebody with CURL could really mess up your day.
- ollysb 12y ago
  I can't see any reason why application logic would be any less robust on the client vs the server. With regards to authorization there's examples from the nosql world, e.g. couchbase's sync gateway[1]. You could argue that you might as well use rails instead but a proxy that's focused on just authorization can be far more performant. [1] http://docs.couchbase.com/sync-gateway http://docs.couchbase.com/sync-gateway
  - andrewstuart2 12y ago
    The reason it's less robust is that I could use curl to send a DELETE request for records I shouldn't be able to delete. Or POST some data saying my order is paid in full. Business logic that matters at all has to be validated by some authority. The client is never good enough.
    - ollysb 12y ago
      That's the purpose of the sync-gateway(in couchdb's case), it handles authorisation of actions against couchdb.
      - andrewstuart2 12y ago
        Just because I'm authorized to create a record doesn't mean it's a valid record. Take my new order example. If all business rules, including payment authorization and payment record keeping, are handled client side, I can easily say that a valid payment has been made when it hasn't.
        ollysb 12y ago
        I can see how there's a class of applications that would need the level of verification you're talking about(payment authorization being a good example). Many apps don't need that level of verification though, an app like trello for instance only needs to authorize actions against an entire resource, not values within a resource.
        mercurial 12y ago
        On the other hand, if your app has no business rules, one would assume that your server-side application is going to be extremely thin.
    - troyk 12y ago
      you can do the same with psql, rails bin commands, php, or anything else that can talk to the db
      - deleted 12y ago
        [deleted]
      - mercurial 12y ago
        Which is precisely why your DB server is behind your firewall.
- ako 12y ago
  As this is basically all the same architecture as client-server 20 years ago, we only need look there to find all the necessary design pattern. Some of the things we used when building applications using oracle 4gl developer tooling: * abstract away the actual tables behind views, so users don't have direct access to the tables, and you can still modify your tables * add a table-api to abstract away direct crud actions on your data. Table api's are 3G plsql modules that contains business logic to validate and update date (in the database). * use vpd (virtual private database) to automatically rewrite queries to include security rules (user and rbac security handled by the database) * have multiple database object owners (scheme) to split up the database object into different modules. Never use scheme owners to access database from your client as a regular app user.

by ollysb 12y ago

andrewstuart2 12y ago

That works fine as long as you never need security or robust application logic. Somebody with CURL could really mess up your day.

ollysb 12y ago
I can't see any reason why application logic would be any less robust on the client vs the server. With regards to authorization there's examples from the nosql world, e.g. couchbase's sync gateway[1]. You could argue that you might as well use rails instead but a proxy that's focused on just authorization can be far more performant. [1] http://docs.couchbase.com/sync-gateway http://docs.couchbase.com/sync-gateway
- andrewstuart2 12y ago
  The reason it's less robust is that I could use curl to send a DELETE request for records I shouldn't be able to delete. Or POST some data saying my order is paid in full. Business logic that matters at all has to be validated by some authority. The client is never good enough.
  - ollysb 12y ago
    That's the purpose of the sync-gateway(in couchdb's case), it handles authorisation of actions against couchdb.
    - andrewstuart2 12y ago
      Just because I'm authorized to create a record doesn't mean it's a valid record. Take my new order example. If all business rules, including payment authorization and payment record keeping, are handled client side, I can easily say that a valid payment has been made when it hasn't.
      - ollysb 12y ago
        I can see how there's a class of applications that would need the level of verification you're talking about(payment authorization being a good example). Many apps don't need that level of verification though, an app like trello for instance only needs to authorize actions against an entire resource, not values within a resource.
        mercurial 12y ago
        On the other hand, if your app has no business rules, one would assume that your server-side application is going to be extremely thin.
  - troyk 12y ago
    you can do the same with psql, rails bin commands, php, or anything else that can talk to the db
    - deleted 12y ago
      [deleted]
    - mercurial 12y ago
      Which is precisely why your DB server is behind your firewall.
ako 12y ago
As this is basically all the same architecture as client-server 20 years ago, we only need look there to find all the necessary design pattern. Some of the things we used when building applications using oracle 4gl developer tooling: * abstract away the actual tables behind views, so users don't have direct access to the tables, and you can still modify your tables * add a table-api to abstract away direct crud actions on your data. Table api's are 3G plsql modules that contains business logic to validate and update date (in the database). * use vpd (virtual private database) to automatically rewrite queries to include security rules (user and rbac security handled by the database) * have multiple database object owners (scheme) to split up the database object into different modules. Never use scheme owners to access database from your client as a regular app user.