3 ms·

You bring up an excellent point against all the folks on here saying Dark Skies should just have had a fallback geocoding service in place. By that logic every

You bring up an excellent point against all the folks on here saying Dark Skies should just have had a fallback geocoding service in place. By that logic every application that uses a third party service should code in a primary and a fallback. That is unrealistic!!

smsm42 12y ago
Why is it unrealistic? For most common services, more than one alternative API provider exists. Why not think about "what would happen if that service I do not control goes down?" and have a plan B ready for that? That's like saying deploying a service on more than one machine in different data centers in case one of them goes down is unrealistic. We've long past that and long recognized that it is not only realistic but necessary once you're on certain scale.
- palakchokshi 12y ago
  The argument is for a smaller business not for a business at a certain scale. You can argue that at a certain scale you can build out your own solutions and not rely on third party APIs, at a certain scale you can purchase the absolute premium platinum support package so you can be sure your email is answered within minutes. At a certain scale you can do a whole lot of things but this is about when you're not at that certain scale. so let's think about context here.
  - smsm42 12y ago
    There's a big difference between using 2 existing geosearch APIs and building your own geosearch API. I'm saying the first one is feasible even for a smaller business.
    - palakchokshi 12y ago
      yes if it was only geosearch API that one had integrate with. It would be manageable to maintain API changes for 2 providers for 1 service. As soon as you increase the number of services you use your solution soon becomes non-trivially complex. Consider a travel app that uses a geosearch API, a mapping API, a weather API and a enroute data points API (attractions, gas stations, hotels, etc.) Would you suggest the app developer to code 8 API integrations, a primary and secondary for each of the services and maintain them for API changes?

smsm42 12y ago

Why is it unrealistic? For most common services, more than one alternative API provider exists. Why not think about "what would happen if that service I do not control goes down?" and have a plan B ready for that? That's like saying deploying a service on more than one machine in different data centers in case one of them goes down is unrealistic. We've long past that and long recognized that it is not only realistic but necessary once you're on certain scale.

palakchokshi 12y ago
The argument is for a smaller business not for a business at a certain scale. You can argue that at a certain scale you can build out your own solutions and not rely on third party APIs, at a certain scale you can purchase the absolute premium platinum support package so you can be sure your email is answered within minutes. At a certain scale you can do a whole lot of things but this is about when you're not at that certain scale. so let's think about context here.
- smsm42 12y ago
  There's a big difference between using 2 existing geosearch APIs and building your own geosearch API. I'm saying the first one is feasible even for a smaller business.
  - palakchokshi 12y ago
    yes if it was only geosearch API that one had integrate with. It would be manageable to maintain API changes for 2 providers for 1 service. As soon as you increase the number of services you use your solution soon becomes non-trivially complex. Consider a travel app that uses a geosearch API, a mapping API, a weather API and a enroute data points API (attractions, gas stations, hotels, etc.) Would you suggest the app developer to code 8 API integrations, a primary and secondary for each of the services and maintain them for API changes?