search

hjfreyer / marry-fuck-kill

http://marryfuckkill.net
Apache License 2.0
2 stars 0 forks source link

Migrate to Custom Search API #19

Closed mjkelly closed 10 years ago

mjkelly commented 10 years ago

Image search API is deprecated: https://developers.google.com/image-search/

There is no shutdown date, though, so it's not urgent. It also could be some work, too, because there are 2 places where we use the image search API, and they're in totally different environments:

  1. Migrate the client-side JS interface in the MFK maker. (GWT App.)
  2. Migrate the server-side checker. (Python.)

Thoughts:

mjkelly commented 10 years ago

Maybe custom search API isn't what we want. It looks like it's designed for searching a specific site.

hjfreyer commented 10 years ago

CSEs can be configured to search the whole web. I think you just don't list any sites there. It's a bit awkward, but it works.

I've been playing around with polymer which is the new hotness (it's shims for what will hopefully be the next standard for the web - very cool stuff), particularly for the voting page, but I agree the maker is in greater need for work.

How about this - you work on hooking the CSEAPI up to python, and I'll work on the maker frontend? I don't think we necessarily need to do "checking" anymore, but proxying the requests through our server would let us sign the results in the future if abuse becomes a problem.

The other issue is that the CSEAPI is payed and the freebie quota is pretty small. As a result, the search-as-you-type functionality would probably have to go, but I think that's fine. We'd just have to keep an eye on the usage. If we proxy through the server we could theoretically switch to a cheaper API fairly easily.

mjkelly commented 10 years ago

Sweet. Converting the existing server side code to use the custom search API was very simple. I'll write a proxy for the client to use in the next few days.

I'll put it all in the 'customsearch' branch: https://github.com/hjfreyer/marry-fuck-kill/tree/customsearch

Polymer looks interesting. I'm a little concerned about browser support -- I think you should check that vs who actually visits the site. No reason to cut people out.

hjfreyer commented 10 years ago

Judging from GA, it looks like ~1% of our traffic is unsupported. And I'm not sure how broken the "unsupported" browsers are.

My inclination is to be in the "move the web forward" camp and assume a self-updating browser (but test unsupported ones, and possibly throw up a banner if it's truly unusable). But I'm interested to hear your input.

Another factor to consider (though it's a bit of an academic exercise), is that polymer encourages designs that improve accessibility (rather than requiring a huge DIV soup where content is indistinguishable from markup). So there's that.

hjfreyer commented 10 years ago

Uploaded angular version of the maker (complete with your new CSS and new GA tags) as version "beta", and enabled 5% traffic split. I'll keep an eye on it and continue the rollout manually unless you have any objections.

Once we're at 100%, I'll merge the the angular branch into master and it'll be an new age of MFK!

mjkelly commented 10 years ago

Awesome! I didn't even realize IP-based traffic splitting was an option on appengine. That's fantastic.

hjfreyer commented 10 years ago

5%, as expected, had negligible CSE traffic (possibly 0). Upped to 50%.

mjkelly commented 10 years ago

Oh, I should update this: Raised to 100%. We're consistently exceeding our 100 free queries, but the total is looking like O($10)/mo. I've got $10.

I consider this closed.