newhavenio / newhavenio.github.io

active version of the website for newhaven.io built on the Jekyll framework
http://newhavenio.github.io/
MIT License
13 stars 12 forks source link

Update to use Meetup API V3 by August 15 #122

Closed caseywatts closed 4 years ago

caseywatts commented 4 years ago

This site uses the Meetup.com v2 api which will stop working on August 15. More details in this issue: https://github.com/tech-meetup-website/tech-meetup-website/issues/6

treznick commented 4 years ago

Thanks @caseywatts ! I'm going to need to delegate this issue to someone else who can own it. 8/15 is awfully short term, and I'm at a loss right now for how to get the authentication flow working with OAuth 2, namely given that our site provides a feed of meetups.

Here's the TL;DR as I see it:

  1. switch our authentication from using a signed api key url to an oauth grant: https://www.meetup.com/meetup_api/auth
    • we'll need to figure out how to get refresh tokens. This may necessitate having an actual back end as opposed to, say github pages. I don't love that.
  2. we'll need to switch our JS to use meetup's new api format
    • that's less difficult, but still a pain

Given the technical difficulty of 1. and the fact that this group is run on volunteer time, I'm tempted to drop the meetup feed in its entirety.

@jhirbour @jnimety @danbernier @thoughts?

sukima commented 4 years ago

Does V3 still have signed URLs? If so that is how it is done.

treznick commented 4 years ago

@sukima unfortunately not: https://www.meetup.com/meetup_api/auth/#keysign

This feature is no longer actively supported. As an alternative, you can use OAuth2.

sukima commented 4 years ago

I am not understanding how that works. Are they saying they expect random people to login though NH.io to see a list of events? I never understood how Meetup could be so confusing.

sukima commented 4 years ago

OAuth removes the need for members to hand over their credentials to you directly.

Um but rendering a list of event/members was never a hand over credentials situation.

(ノ°Д°)ノ︵ ┻━┻

sukima commented 4 years ago

Looking further Meetup's official recommendation is to use a client lib. Sadly both client libs available haven't been updated in either 4 or 6 years!!

It also seems all the API examples assume you are writing an app to give to Meetup users. I haven't found any examples of websites using it to re-display meetup data on their site.

I have a sneaking feeling Meetup is intentionally making that concept obscured and would want people to just link to meetup (to force more site views) then use an API.

That being the case I wonder if we could hack it with some JSONP instead of going through their public API. Or have a scrapper running on heroku to provide the data. Thoughts?

sukima commented 4 years ago

The page that has that information looks like it derives the data from a <script> tag that has an injected JSON payload. My best guess is that the information is not available unless you scrape the HTML. That is doable in JS land but seem very over the top for a static website.

I recommend contacting Meetup and seeing if they have more in context advise.

treznick commented 4 years ago

Um but rendering a list of event/members was never a hand over credentials situation.

@sukima that's not entirely accurate. We used (I believe @jnimety 's) credentials to sign the urls, so in a sense they are handed over, just not over an http request.

As for meetup's motivations, I suspect oauth is being rolled out for security reasons. Also I suspect that they probably want automation that engages more with meetup, as opposed to just displays meetup content.

Scraping is probably a non-starter. That's too volatile

Honestly if we're building a backend service, it can do the oauth flow and use the refresh token to get new creds if they expire. It can also proxy the api. But keep in mind, this means that we have:

  1. another service to maintain on what is borrowed time and negative budget and,
  2. another service that can go down and take the site down.

What I think realistically we need is an honest assessment of whether or not we need meetup event data at all (or, frankly, a website at all gasp). This is static data to advertise our meetups, and at the moment we have literally zero analytics into what marketing channels are effective. Most likely slack is our most effective marketing channel, and meetup's own notifications/subscriptions. Having the meetup data on the site is a nice to have, but it's not strictly required.

Plus it means we get to delete a bunch of old code that's fairly insecure, and that we don't need to worry about @jnimety 's creds rolling

jhirbour commented 4 years ago

For the amount of meetups up we have, it seems like we could manage a static page with just GH prs.

bmack123 commented 4 years ago

After spending an hour or 2 on it, I am for dropping the meetups on the page. It isn't trivial to make a rails server, someone would have to hand log in if we ever forgot to refresh the token, and we would need a cron job to request more meetups/refresh, then we would have to keep the server up and running so that it could server the meetups in less than 30 seconds.

That means the developer page goes too. The contact loads a google group whose last post was in 2017. That basically makes the page a glorified slack button. That is useful enough for me to think we should keep it around, but I'm not opposed to dropping it altogether and letting slack be our main medium of exposure.

wley3337 commented 4 years ago

Hi All! I know the general consensus has been to drop the MeetUp features, but I had some time this weekend and wanted to look at this for one of my own projects so I figured I'd template it out. It has a React front and a Rails backend (with Postgres) for the exchange of the token. I tried to comment/document each step and what was added. You can find them here:

React Front

Rails Back

The front is a bit janky getting it to work as a demo without too much CSS and logic so please don't judge me to harshly. Happy to answer any questions about it and feel free to use the code as you all see fit.

treznick commented 4 years ago

for reference: #123

@wley3337 thanks for putting the effort into those proofs of concept. Given the time frame we're under, I think the plan right now is to merge #123 and circle back. I'll file a new issue so we can thread discussion about how to deal with an events (and maybe a developers) section after the v3 api epoch. But I'll back link to here, and we can give your solution a kick in the tires.

Again, thanks for taking the time to put that together.

treznick commented 4 years ago

Closing this to mark that we've resolved the v3 issue temporarily. Let's continue the conversation in #124