Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I work for a startup that has mapping/routing as one of its core needs - about a year or two ago we decided that our reliance on Google's mapping APIs was too great and decided to work on having a switchable backup provider in case something like this should ever happen.

With auto complete especially, we would have had a 10-20x increase in pricing (and this is with an 'enterprise' plan pricing). As the article says, we were basically given 2 months notice for an enormous price hike that would likely render the business untenable. Luckily we were able to put our backup plan into action, but changes like this really erode the confidence to use Google (at least for mapping) in the future unfortunately.



I'm curious about how the conversations between Google and customers went about this change.

I'm finding it really odd Google would just fuck their customers over this way. They must have known how it affects startups in particular. What were the conversations with Google like?

Just one-sided "This is the new price, take it or leave it!"? Or something else?


> I'm finding it really odd Google would just fuck their customers over this way.

Why is it odd?

If you're on a free tier, you're not really a 'customer', just a user.

If you're a 'startup' you probably have funding. If not, you're not the sort of 'startup' that will fit in their calculations.


Any details on how complicated enabling that switchability was? Or details / costs / takeaways from your process?

Seems like now would be a great time to write a blog post on how you did it. :)


It definitely took a decent amount of work (and a double decent amount of testing).

As voltagex_ mentioned, most location providers have a different API flow than Google Maps - rather than doing a total abstraction of providers (which would take too much effort), we went for a Google flow and non-Google flow basically.

For example, location autocomplete with Google requires a two step process (call for suggestions, then call for details of the suggestion) where a couple alternative apis provided the necessary data in the suggestion process. This requires a bit of a different flow on the server/client, so building support for both in was one of the hurdles we had to get over.

As for other takeaways, I guess mainly always have a backup plan for mission-critical service providers :)


Writing a mapping abstraction layer is tricky - mostly because Google Maps does things differently than other providers. Can you share any details?


No need to write it yourself - the article mentions using Leaflet https://leafletjs.com/ for just such a purpose.


When I last looked at this, using Google Maps tiles with Leaflet was against the ToS.


Right, just using the plain gmaps tiles in a Leaflet tile layer is against the google TOS. But there is a Leaflet plugin that puts the whole google map component in a TOS-compliant way as a layer into leaflet and keeps both in sync with DOM observers. Sounds pretty weird but works perfectly in production.

https://gitlab.com/IvanSanchez/Leaflet.GridLayer.GoogleMutan...


Probably spirit vs letter of the law there. Hopefully performance has improved since the last time I looked (3 years ish)


It's a contract, not yet a law (thanks btw). Contracts are usually taken pretty literally if the judge who decides sees significant time being put into the contract to make it include all forseable cases.


I would be interested in the details on this as well, as we heavily use mapping, routing/directions, autocomplete.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: