4 ms·

For many years now, more and more code has been moving to the client side. At this point, for me, PHP is just the glue between the database and the client side

by maratd 15y ago

For many years now, more and more code has been moving to the client side. At this point, for me, PHP is just the glue between the database and the client side code. There's nothing left to hate. Move on already.

rbanffy 15y ago
There still has to be a lot of glue logic on the server. When your client-side code calls something like "validate_purchase" on the server, you'd better have some trusted code handling that.
- maratd 15y ago
  > When your client-side code calls something like "validate_purchase" on the server, you'd better have some trusted code handling that. Why am I calling "validate_purchase" on the server? Client Clicks Buy -> JSONP to Payment Gateway -> Gateway to Server (with all the info) -> Server to Client Confirming Transaction All my server is doing is recording the transaction and forwarding the info to the client. The gateway is trusted, since they are processing payments. I'm serious. This is where we're headed. Yes, you will have a hell of a lot of server-side code on the gateway, but that's a service, not the application.
  - amalcon 15y ago
    Your payment processor isn't going to know how much anything costs. You'll need some (server-side) validation logic if you don't want people buying new high-end smartphones for a penny. Which event invokes that logic is immaterial.
    - maratd 15y ago
      > Your payment processor isn't going to know how much anything costs. So? > You'll need some (server-side) validation logic if you don't want people buying new high-end smartphones for a penny. That validation logic should be expressed in SQL. It's really really simple. If inventory id and price match in your inventory table, insert into your transaction table. Again, see my original point. PHP is just the glue for the database.
      - pak 15y ago
        Hmm. Not to nitpick, but what if: - you're running a promotion - the price changed in between the time the person added it to their shopping cart and checkout - two people are processed for a payment on the last item in inventory at the same time - there are different options on the item, e.g. color, that change the price - other people bought the last item in inventory already, but there's an equivalent product at the same price - the person bought the product using a combination of real money and gift card money, which the payment processor does not handle - the person bought other things in the same transaction, e.g. a gift card, that do not have an inventory ID Those are just a few cases off the top of my head, but the short end of it is that expressing all of this with a combination of SQL and client-side logic is just madness. If you're saying that we don't need to write business logic in PHP any more, I think you just don't work with the same constraints that most businesses do.
        moheeb 15y ago
        All of these, save for the payment processor one, can and should be done in sql. I think you are uncomfortable with SQL. Ultimately it is the designer's choice where the business rules are handled...but to abstract those rules to levels above where the 'business' actually happens seems like a poor practice.
        pak 15y ago
        'Business' does not just happen within the database! You will have to perform logic based on events that occur elsewhere, e.g. on the network or within outside data sources! And to say that something should be done in SQL just because it can is patently absurd--do you know how much performance suffers as soon as you start roping in subqueries and calculated values? Half of the things I listed would require stepping outside of indexed columns in awkward ways--that was kind of my point. Good luck keeping that performant past a few million rows. In fact, I would love to see you design a query that branches on the condition that the item is out of stock and automatically returns the top 3 equivalent parts for each brand using a junction table containing equivalencies, ordered by a column in the junction table containing the closeness of fit. Go ahead, humor me. Then try to pretend that that query will ever stand up under scale.

by maratd 15y ago

rbanffy 15y ago

There still has to be a lot of glue logic on the server. When your client-side code calls something like "validate_purchase" on the server, you'd better have some trusted code handling that.

maratd 15y ago
> When your client-side code calls something like "validate_purchase" on the server, you'd better have some trusted code handling that. Why am I calling "validate_purchase" on the server? Client Clicks Buy -> JSONP to Payment Gateway -> Gateway to Server (with all the info) -> Server to Client Confirming Transaction All my server is doing is recording the transaction and forwarding the info to the client. The gateway is trusted, since they are processing payments. I'm serious. This is where we're headed. Yes, you will have a hell of a lot of server-side code on the gateway, but that's a service, not the application.
- amalcon 15y ago
  Your payment processor isn't going to know how much anything costs. You'll need some (server-side) validation logic if you don't want people buying new high-end smartphones for a penny. Which event invokes that logic is immaterial.
  - maratd 15y ago
    > Your payment processor isn't going to know how much anything costs. So? > You'll need some (server-side) validation logic if you don't want people buying new high-end smartphones for a penny. That validation logic should be expressed in SQL. It's really really simple. If inventory id and price match in your inventory table, insert into your transaction table. Again, see my original point. PHP is just the glue for the database.
    - pak 15y ago
      Hmm. Not to nitpick, but what if: - you're running a promotion - the price changed in between the time the person added it to their shopping cart and checkout - two people are processed for a payment on the last item in inventory at the same time - there are different options on the item, e.g. color, that change the price - other people bought the last item in inventory already, but there's an equivalent product at the same price - the person bought the product using a combination of real money and gift card money, which the payment processor does not handle - the person bought other things in the same transaction, e.g. a gift card, that do not have an inventory ID Those are just a few cases off the top of my head, but the short end of it is that expressing all of this with a combination of SQL and client-side logic is just madness. If you're saying that we don't need to write business logic in PHP any more, I think you just don't work with the same constraints that most businesses do.
      - moheeb 15y ago
        All of these, save for the payment processor one, can and should be done in sql. I think you are uncomfortable with SQL. Ultimately it is the designer's choice where the business rules are handled...but to abstract those rules to levels above where the 'business' actually happens seems like a poor practice.
        pak 15y ago
        'Business' does not just happen within the database! You will have to perform logic based on events that occur elsewhere, e.g. on the network or within outside data sources! And to say that something should be done in SQL just because it can is patently absurd--do you know how much performance suffers as soon as you start roping in subqueries and calculated values? Half of the things I listed would require stepping outside of indexed columns in awkward ways--that was kind of my point. Good luck keeping that performant past a few million rows. In fact, I would love to see you design a query that branches on the condition that the item is out of stock and automatically returns the top 3 equivalent parts for each brand using a junction table containing equivalencies, ordered by a column in the junction table containing the closeness of fit. Go ahead, humor me. Then try to pretend that that query will ever stand up under scale.