Questions / Answers to/from LinkedIn Iris team

[ChrisCarini]

TL;DR:

1. Filters sound good. Consider decreasing limit from 500 to ~20 - this can prevent a bad UX when an Iris application generates a flurry of incidents at the same time.
2. 5 second delay between polling requests is likely ok - set to 60 seconds to be even more reasonable (and if wide adoption happens)
3. The min/max delay between incident being created and messages being created (few sec to few min) found during testing is likely accurate - this can vary based on several factors.
4. To have a user auth for claiming an incident, the plugin could POST to the /login route with the user's username/password, keep track of the returned iris-auth cookie, and submit that in your request to claim the incident. Downside is we need to keep track of user credentials.

Details

Below is an email I sent to the LinkedIn Iris team back on 2019-01-02:

Hey Iris / MonInfra Team,

Below are two seemingly random questions, and a single feature request! But first, a bit of context, in hopes of these
questions being slightly less random: I’ve been working on an IDE plugin (OSS side project, not specifically for
LinkedIn; if interested, it’s here -> https://github.com/ChrisCarini/iris-jetbrains-plugin ) over holiday shutdown to
display Iris notifications w/in JetBrains IDEs, screenshot below (see bottom right corners of the 2 IDE windows for the
notification):

(Note: Clicking on the “Claim ######” takes the user to the Iris page to claim the incident – I have plans to add
more information around the incident in this notification, and would also desire that invoking(ie, clicking) that action
would claim the incident w/o the user navigating to the web UI first.)

Questions:

1. How many QPS can the API endpoints handle?
   1. Context: Because there’s no good way to ‘push’ notifications to JetBrains IDEs, I’m polling the Iris API in
      order to obtain information about incidents. Specifically: “GET /v0/incidents”, limiting the query as much as I
      can – active only, limiting to 500 results, targeted to a specific user, created recently (user configurable, up
      to 125 sec ago), and limiting the fields in the response. I’m not worried about Iris API when there are only a
      handful of users using this plugin as that’s pretty minimal additional QPS to Iris overall, but if several
      hundreds / thousands of users start using it, that could amount to something more worrisome IMO.
   2. Reasoning: I’ve made the frequency of polling configurable to the user, but I’d like to provide some sane
      options for the user to select from; at present, they can select anywhere between 5 and 125 seconds. I’m trying
      to balance ‘requests sent to Iris’ and ‘staleness / lack of notification in IDE’. Is 5 sec too frequent? Curious
      on the team’s thoughts.
2. What’s the min/med/max delay between an incident being created and the message(s) being created?
   1. During testing (testing in the webUI is super handy, by the way!), I’ve noticed it can be anywhere between a few
      seconds, and a few minutes – I’m assuming it’s based on the number of incidents / messages being created w/in the
      system, but it would be handy to know what a reasonable range here might be. To accommodate for this, I’ve
      exposed a setting in the plugin to allow users to manipulate the amount of ‘lookback’ when querying the API (
      specifically, when limiting the ‘created’ field) to be anywhere from 5 to 125 seconds. Having the min/med/max
      would allow me to pick a more sensible range to allow users to select (or, even better user experience, not have
      them pick at all).

Feature Request:

• Add a way to allow users (as opposed to applications) to authenticate for API requests
  • Based on the documentation I’ve found (and doing a cursory
    glance into the Iris source code), it seems that the only way to authenticate against the API is by having an
    application – would it be possible to also allow users to authenticate for certain requests? (specifically for my
    plugin, I’m looking at the “POST /v0/incidents/<incident_id>” endpoint for claiming an incident).

Best,

Chris Carini

LinkedIn Iris team response (Joe G)

Hi Chris,

Neat plugin. 😊 To answer your questions:

1a) The filters you described sound good. It might also make sense to decrease your limit from 500 to maybe 20 or
so. Sometimes, some non-autoalerts Iris Applications generate a flurry of incidents all at once, which could lead to bad
user experience in your plugin as well as a large amount of data returned.

1b) 5 seconds is likely okay; but to be on the safe side, every 60 seconds may be more reasonable, especially if
your plugin becomes widely used. Other people on the Iris team might have more thoughts on this.

2a) The min/max you found during your testing is likely accurate. The delay between incident creation -> first
message depends on several factors, such as the number of iris incidents/messages currently being created.

And your feature request:

1a) The preferred method for this functionality is currently to use a custom Iris application/api key.

To avoid using a custom application, you could have your app manually POST to the /login route with the user's
username/password, keep track of the returned iris-auth cookie, and submit that in your request to claim the incident.
But this has the caveat of your plugin needing to prompt/keep track of a user's credentials, which isn't ideal from a
security point of view.

Let us know if you have further questions.

Regards

[ChrisCarini]

@all-contributors please add @jrgp for ideas, question, research

[allcontributors]

@ChrisCarini

I've put up a pull request to add @jrgp! 🎉

[jrgp]

Thanks for the shout out :)