fs-challenge

This repo hosts the backend service responsible for consuming webhook events and creating github issues. This service is a simple example of a cool thing that could be done using the FullStory API/Webhooks, but is somewhat limited in scope due to my non-enterprise free trial account. It has a singular route /handleNote that creates github issues against the MovieSearch repo when recording session notes are created containing the hashtag #issue. The route is triggered by webhooks from FullStory's API.

Google has created a go library for using github's api. For the sake of time I utilized this. https://github.com/google/go-github

I also made use of the oath2.0 library for auth. https://github.com/golang/oauth2

Thoughts / Things I would do with more time.

If I had full access to an enterprise account there would be a couple more features I'd implement mainly automatic issue creation when certain events reach a threshold. E.g when there are more than 500 rage clicks in the span of 4 hours. It would also be great if fullstory's API had configurable thresholds for ajax errors grouped by URL. There is a bug in my moviesearch app which makes an api request with no query which returns an error, with the previously mentioned feature I could be notified when it occurs through a webhook.

Due to the aforementioned limitations/time constraints there are also a variety of concessions I made.

1. The route does not authorize and verify the request is coming from Fullstory. This is obviously a no-go in a real production application.
2. Multiple notes per FullStory session create comments after the initial issue is created. This forces one note per a session which is a bit restrictive but less messy than creating individual issues for each note in the same session.
3. Regex string parsing isn't the best way to determine which notes are meant to create issues. If I was creating an integration like this one from the ground up I would provide a Create Github Issue button which could bring up a modal with more useful fields/functionality that could control this behavior better. E.g Issue Title, Assignee, Projects, Labels, etc.
4. If this was a real integration in fullstory's platform it would obviously need to be considerably more configurable. There is a lot of hardcoded values. E.g Github username, repo username, etc.
5. The service lacks proper test coverage. I made the decision to not write tests for the majority of the functions due to them being mostly wrappers for API calls. If this was a production level application I'd write tests for every method and use dependency injection to avoid polluting the code with external library structs/to allow mocking of external library functions.