Closed otagi closed 8 years ago
The BRUG website uses it https://github.com/brug-be/brug/blob/master/app/models/meetup_event.rb
the only concern I have is then to put every event there. but that's the goal. so :+1:
I tried with simple code:
def events_data
response = open("https://api.meetup.com/brug__/events?fields=group_photo").read
JSON.parse(response)
end
Works well, pretty simple. The only issue for now is the group photo, because the layout expects a fixed size.
The class is nicer, though. I'll use that instead.
I'm hitting a conceptual roadblock here...
Middleman pages are, by design, static. Meaning that with the code above, or even with a beefed-up class, the events data will only be refreshed when the app is rebuilt / deployed. It only marginally improves the current manual editing process.
I see 2 solutions to have a more automatized events list:
I'm way more fond of the second solution, but any input is welcome.
I see a third one: a scheduled task (on heroku?) updating it and deploying it
of course a Rails app would help to make it dynamic, but then we enter in other issues such as hosting.
Even if I'm not fond of, I'd prefer the 1st option to the 2nd for that reason. That's why the 3rd option could be a good one. (especially considering that it's not like the events are created so often).
I'd head towards option 1 and 3 too, 1 being the easiest in my opinion
1 seems the easiest indeed.
where do you keep the secrets then in the first solution?
Api key for meetup is not really a secret is it ?
Not sure why the api key is needed, @otagi example url is https://api.meetup.com/brug__/events?fields=group_photo
doesnt it do the trick?
The API key should be kept secret https://secure.meetup.com/meetup_api/key/ as it is linked to one account. I won't allow mine to be public.
according to my knowledge, and what I read in the doc, you need to provide that key for some requests on the API meetup. After a quick check it seems that https://api.meetup.com/ruby_belgium/events
doesn't need an auth scope. I don't know if they limit the rates in the case of public request.
Ok then 1) is not an option :)
1 could be an option if it is confirmed that the requests we use can be made publicly
PS: sorry I wanted to write it doesn't need an auth scope
as you can check by yourself
I will test solution 1 without the API key. Might do the work. Thanks for the feedback!
You can test solution one with a simple proxy that has the key
@otagi Did you have the time to have a look at this ?
Simon sent me a javascript he used on one of his sites. I'll adapt it for here.
The events section is not always up to date, as I have to manually edit the yaml file, and sometimes I forget about it.
Meetup has an API that we could use for that.