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

See previous entries: 3, 2, 1.

I track the progress of Exist Integrations v2 in my mind based on re-creating the existing integrations in the new code base. In November I made incredible progress and got to 50% of the integrations ported over. This is probably a detriment since they are more than simple ports as new functionality is being introduced in the form of custom attributes that were impossible to track before. After I finished with Trakt, I stopped working on the site. Knowing that 50% is a failing grade, I did feel bad. There were the holidays. There also were a surgery to correct some broken toes that all robbed available time to spend on Exist Integrations. It was understandable.

There are still a lot going on, but I’m happy to say that I got to 75%. You Need a Budget has been moved into the new framework. I have introduced two new attributes that can be utilized: Money earned and Money saved.

I’ll go through the Pull Requests, but before I do that I realized that the Roadmap was badly outdated. Certain elements were lingering in the backlog that I deemed too difficult. I asked myself if I would ever have the time to work on some of them. Honestly, I don’t have unlimited time to work on this hobby so I had to make the call that they would be rejected. Having a clean backlog did make me feel better. I’ll be keeping it updated as development progresses.

PR #14 - Global Messages

One of the things I realized is that informing users of what is going on is important. I added a quick support for global messages that can be presented to the users of the site.

PR 15 - Handle 401 Unauthorized

Between now and the release of the Trakt processor in v2, Trakt experienced a database issue that took the site offline for almost a week. The API was offline. It would return 401 unauthorized. When I was seeing those in the logs I realized I forgot to handle that use case. With OAuth 2, users can go on a service and revoke a token. If Exist Integrations doesn’t handle that accordingly it will continue to try until the end of time. This isn’t ideal.

I made the call that if Exist Integrations gets a 401 from the API that it would treat that as a disconnect from the user. The disconnect workflow is triggered automatically.

PR 16 - Log View

It’s great that Exist Integrations can automatically disconnect you, but it never notifies you. Someone had suggested to add functionality to notify you. The privacy policy didn’t permit me to email any of the users, but I took the suggestion to heart. I logged all connect and disconnect initiations and put in a log view. It also includes the hourly logs from the different processors.

I didn’t care too much about making this look pretty.

PR 17 - Static Pages

It was around this time that I looked at the other pages outside of the true integrations. I needed to get the Privacy Policy, the About page, the Landing page, and the Integration details migrated over. I took advantage of this time to amend the Privacy Policy to allow for emails if an integration is disconnected. It’ll be implemented in the future.

All the pages are now done. I also came up with the plan to migrate the users over to the new codebase. Once I have finished the YNAB and Toggl Track, I will email all of the users who have an enabled integration on Exist Integrations v1. I will give them 7 days headstart of the launch. The users table will be migrated over from v1 to v2 so that the users can continue to login. Then they will have to re-configure each integration.

PR 18 and PR 19 - YNAB Integration

Thankfully I did the work with the WhatPulse and Trakt integrations as it made configuring the initial connection to You Need a Budget really easy. YNAB does introduce an added challenge. There are categories for each budget that needed to be able to be configured to be: Ignored, connected to official attribute Money spent, connected to custom attribute Money earned, and connected to custom attribute Money saved.

I handled this through the YNAB management. After you connect to YNAB, Exist Intgrations will pull all of the categories for the budget. Each user must configure each category through a dropdown.

The processor introduced some challenges. Transactions imported into YNAB can have dates and values change. I’m looking mostly at credit card transactions that aren’t finalized until they are posted. I had to come up with the appropriate logic so that the totals will be properly sent. Exist Integrations v2 uses the increment endpoint on Exist, so I had to make sure that if the date changed that the existing transaction has a negative amount posted so the total equals 0. With that, when the value changes only the delta will be saved. Each transaction can be summed to get the right value that would be incremented in Exist.

This posed several challeges that I decided to postpone addressing. YNAB supports splitting a transaction into different categories. This introduces a headache if you consider a transaction can be split and then combined or vice versa. I made the call that subtransactions won’t be supported in the initial implementation. I also made note that deleted transactions aren’t properly being sent through the YNAB API with how I’m making the call. There is likely a way to handle it, but the delays of getting this out was really bugging me. Instead of over-engineering it, there is a workaround with the Zero Data functionality.