3 ms·

This is very standard with web scraping implementations. Honestly, if you are reversing someone's protocol or scraping their web site, you are stupid if you put

by lnanek2 13y ago

This is very standard with web scraping implementations. Honestly, if you are reversing someone's protocol or scraping their web site, you are stupid if you put the implementation on the client because it will break all the time. Instead you put it on a server where you can fix breaks instantly. The server usually delays/shows stale data while things are broken as well, then does what it can to replay once fixed.

elyase 13y ago
On the other hand putting things on the server means that you can get cut (by IP) and also brings the need of dealing with scaling problems.
- toomuchtodo 13y ago
  You can always scale easier on the server platform, as well as spin up new instances with new IPs on any VM platform. Handling it on the server allows you some control over the chaos. Not so much when all the logic is on your mobile app.
  - marcc 13y ago
    You aren't suggesting that it scales easier on the server than on the mobile client, are you? Nothing would scale better for this app than putting the logic on the client -- it's a customer's phone communication with an Apple server. This leaves nothing for him to scale, anywhere, except for engineering to push out updates.
    - toomuchtodo 13y ago
      I wouldn't say you're scaling properly if you have millions of mobile clients failing to make the proper calls to a service because the protocol has been changed. I'd say its damn near irresponsible to do that. It's not scaling if you're just throwing packets against the wall when the protocol or service unexpectedly changes.
- sil3ntmac 13y ago
  The impression I got was that actual requests and responses are still made by the client.
inafewwords 13y ago
>stupid if you put the implementation on the client because it will break all the time Makes some sense to do Apk downloads for this unusual implementation of it allows a fix push

by lnanek2 13y ago

elyase 13y ago

On the other hand putting things on the server means that you can get cut (by IP) and also brings the need of dealing with scaling problems.

toomuchtodo 13y ago
You can always scale easier on the server platform, as well as spin up new instances with new IPs on any VM platform. Handling it on the server allows you some control over the chaos. Not so much when all the logic is on your mobile app.
- marcc 13y ago
  You aren't suggesting that it scales easier on the server than on the mobile client, are you? Nothing would scale better for this app than putting the logic on the client -- it's a customer's phone communication with an Apple server. This leaves nothing for him to scale, anywhere, except for engineering to push out updates.
  - toomuchtodo 13y ago
    I wouldn't say you're scaling properly if you have millions of mobile clients failing to make the proper calls to a service because the protocol has been changed. I'd say its damn near irresponsible to do that. It's not scaling if you're just throwing packets against the wall when the protocol or service unexpectedly changes.
sil3ntmac 13y ago
The impression I got was that actual requests and responses are still made by the client.

inafewwords 13y ago

>stupid if you put the implementation on the client because it will break all the time Makes some sense to do Apk downloads for this unusual implementation of it allows a fix push