Data Engineer. Tinkerer. Writer.

Exist Integrations Developer Log 3

This is the third development log for my project Exist Integrations.

See previous entries: 2, 1.

The hard part about of new integrations with Exist should be understanding the data. Before I did the clean-up of the UI and backend, the entire process was hard. I am so thankful that I spent the time to clean-up everything in my last development cycle. I completed the migration of the Trakt integration in three total days. I only coded on two of the days for Thanksgiving celebrations.

With Exist API V1 I could only send data to specific attributes. I use Trakt to track my movies and TV watching habits. There was only one attribute I could use: ‘Time watching TV.’ My integration summed up the total time watching movies and TV.

Now, with Exist API V2 I can create attributes. I am taking this opportunity to split the totals. I send time watching TV into the ‘Time watching TV’ attribute. I send time watching movies into the custom ‘Watching Movies’ attribute. This does pose a challenge with the intent of the attribute. I considered doing something special. I decided against it because Exist handles changing attributes well. It prioritizes data over the last 90 days when showing charts or collecting insights. When users change over, this will be something they will need to understand.

Trakt data sent to Exist with the two attributes

For those interested, I handled this work through three changes into the main branch.

PR #11 - OAuth Flow for Trakt

The WhatPulse API is an open web page that returns JSON. The Trakt API is not open. I need the users consent to pull data from their account. Trakt uses an OAuth 2.0 workflow. This is not a surprise since I handle this already with Exist. I did have to set up the services for the third-party integrations to use the work I did for Exist. I made the decision to keep the Exist flow separate since that is the fundamental layer the site of the site. Now, future integrations will go smoother if they use OAuth.

PR #12 - API wrappers for Trakt

Between PR #11 and PR #12 I made the decision on the two attributes I mention above. This let me pinpoint the exact API calls I will need to call in the processor. The Trakt API returns everything in JSON. I need to make sure I can interact with that JSON and get the data I need. I created the Data Transfer Objects so I can interact with the data easier.

My framework uses spatie/data-transfer-object. It’s been very good. As I write this I now see that they have deprecated it. It’s replaced with Laravel-data. That work is now on my backlog. This is the joys of development and helps explain my slow progress.

PR #13 - Trakt Processor

I put everything together with this pull request. Since all API calls were already supported and tested, this went fast. I spent less than an hour migrating this logic to the new framework.

Now, I’m testing the Trakt integration with my user!