Feature: Migrate Events API to a PHP / Laravel App and Upgrade to Meetup.com GraphQL API

[allella]

Reposting the #hg-labs conversation.

This is perhaps a bigger feature than usual, but if I were to direct some energy to an issue, we could considering rewriting the Events API, perhaps as a Laravel app (or extension of the existing HG Laravel app), and in conjunction with a Meetup.com upgrade to their new GraphQL API.

The current Python events API is nice in its simplicity, but it lacks a database and we don't have much in the way of active Python devs.

PHP, via the HG website repo, has attracted our most active contributors, and it was my core language when I was a paid dev, so we could look to build off that momentum.

The Events API does serve outside apps, like the OpenWorks dashboard, so we would still need it to be a public API. If we did rewrite the Events API, it may be worth moving to Meetup.com's new GraphQL API because there is no telling when they might sunset the legacy API we're using. If they decide to sunset the current API, then it would force us to scramble to meet some deadline, or just break everything we're doing with the events API.

I see that we could possibly leverage event "topics" / tags that organizers apply to their events as part of the newer Meetup.com API . That would require coordination with the organizers, but it might allow future features.

I think Meetup.com's GraphQL API requires a "Pro" account, but we could figure that added expense out with donations as part of RefactorGVL consolidation. The existing https://www.meetup.com/hack-greenville/ would be moved under RefactorGVL as part of the MOU we're discussing.

We could move to an events.hackgreenville.com subdomain as part of this process and redirect the old domain to maintain compatibility. Though, I think most of the "consumer" apps of the Events API are things this HG Labs group is running.

[bogdankharchenko]

Some questions and ideas.

• [ ] How do we currently manage which event pages to fetch?
• [ ] Schedule zoom call to do a bit of planning
• [ ] Instead of creating a brand new Laravel app, we could add a subdomain to the current application, as you propose, events.hackgreenville.com which will serve as the API, by doing this we could eliminate the need of having another app, database, deployment workflow, and simplify code bases.

[allella]

Related to the Events API re-write conversation, Carolina Code Conference used Tito for their events and it seems to have an API.

I've asked Chris with Grok what service they are using. It would be good to be able to auto-grab any new events from services like this when orgs don't use Eventbrite for their confernce.

I'm not sure if Tito is the new hip thing people will be using, but it does have an API, so it's got that going for it if we can pull the events with any ease.

[ThorntonMatthewD]

I may be getting ahead of myself here, but I just wanted to confirm that the hackgreeenville.com site is sitting behind Apache (it appears so, but I have seen some mentions of nginx in some of the repos).

Whenever the time comes, how do you all feel about leaving the existing API up in tandem with whatever we elect to move to? We could split the traffic in Apache with a weighted load balancer and do something like 80% of Events API traffic going to the existing setup with the rest going to the new setup. As we gain confidence we can gradually move more traffic over to the new API.

[allella]

We're not aware of any apps using the API besides the ones we're supporting, so I don't think we need to worry about breaking anything with a URL change. Plus, we can setup a redirect to at least provide the new URL.

Honestly, I'd like to know if anybody we don't know is using the API, so we can get them involved.

[allella]

The current hosting is Apache. Eventually it would be nice to put the APIs, and HG site, behind CloudFlare / similar so we have the benefits of redundancy, speed, DDoS filtering, and such.

[bogdankharchenko]

We should definitely put a load balancer behind the hackgreenville servers - great idea for sure - cloudflare is also excellent.

I can handle setup if necessary.

[ThorntonMatthewD]

https://hackgreenville.com/api/homepage/events

Would it be preferable to have a route for external use distinct from the one above? I'm not sure if there are long-term plans to have some sort of auth around these endpoints, and if the existing one would remain for internal purposes. If not, it may be nice to have a single point of ingress for events.

[allella]

Yeah, I'd expect we might change the existing API to a new HG subdomain, but this is all up for discussion.

https://events.openupstate.org/api/gtc

[ThorntonMatthewD]

Evolving filter wishlist for the /v2/events API's primary GET routeI:

• Date range
  • Have some default-- like next 14 days?
• Group
  • By name
  • By ID
• Venue?
  • ID
• Location
  • Zipcode
  • City
  • Distance from point (lat/long or zip) to make things spicy (as a stretch goal)

I don't know if querying by upstream event service would make sense or not (like Eventbrite or Meetup), but the info is there if we wanted that.

[allella]

Look at Bogdan go. Nice.

The API has date and "tag" filters.

I'm not sure what "Group" means in the context above, but the tags in the Orgs API allow for making up vocabularies and applying them to orgs. For instance, tag id 1 is for things we've tagged as worth displaying on OpenWorks' dashboard.

Venues may be harder than expected because the data is not typically normalized by the event management systems and organizers will find all sorts of ways to leave out or put in wacky variations that lead to duplicate venues and other problems mapping orgs or events to a consistent set of venues.

Location could be less of a problem, but it's also potentially ripe for organizers to put in unnormalized data, or for a venue to change, so the location can't be for the organization or its normal location, but rather for the event.

[ThorntonMatthewD]

I think being able to filter by created_at would be good for incrementally pulling new events.

[ThorntonMatthewD]

Current filtering functionality for meeting feature parity:

Date range

curl --request GET \
  --url 'https://events.openupstate.org/api/gtc?start_date=2023-10-01&end_date=2023-10-31&tags=1' \
  --header 'Content-Type: application/json'

Organization Tag

  curl --request GET \
  --url 'https://events.openupstate.org/api/gtc?tags=1' \
  --header 'Content-Type: application/json'

Response Format

  curl --request GET \
  --url https://events.openupstate.org/api/gtc \
  --header 'Content-Type: application/json+ld'

[ThorntonMatthewD]

Moving this over from Slack:

For some of the research being done into the feasibility of switching to Meetup's GraphQL API their "GraphQL Playground" has been helpful for feeling out what's offered: https://www.meetup.com/api/playground/#graphQl-playground

Sample query:

  groupByUrlname(urlname: $groupSlug) {
    name
    city
    state
    upcomingEvents(input: {first: 10}) {
      count
      pageInfo {
        hasNextPage
        endCursor
      }
      edges {
        node {
          id
          title
          eventUrl
          description
          dateTime
          endTime
          going
          status
          venue {
            name
            address
            city
            state
            postalCode
            lat
            lng
          }
        }
      }
    }
  }
}

[allella]

Closing this issue since https://github.com/hackgvl/hackgreenville-com/pull/186 migrated the existing Events API to Laravel and we have the existing issue about the GraphQL Meetup.com conversion with more details and I copied Matt's post above to that issue.