urbanccd-uchicago / api_of_things Goto Github PK

There are a few issues that popped up on Sentry where bad parameters caused 500s. These are things like empty strings (thanks to the awfulness of Apiary) and single values where lists are expected.

https://sentry.io/share/issue/39b450f43ef843509615bff63bafa8e1/
https://sentry.io/share/issue/ea88dc730cf24d2baec7efc9b24a6564/
https://sentry.io/share/issue/5d88abcd58c8476ba896652e3c9d4f78/

Right now /api redirects to the docs. I think this is bad. I'd prefer to return some JSON with information users would find useful.

{
  "docs": " apiary link ",
  "endpoints": {
    "projects": " /projects link ",
    "nodes": " /nodes link ",
    "sensors": " /sensors link ",
    "observations": " /observations link ",
    "raw observations": " /raw-observations link ",
  },
  "clients": {
    "python": " github link ",
    "javascript": " github link ",
    "r": " github link "
  }
}

Tagging in @HeyZoos for comment on this.

Add Sentry plugs and wire it up to Slack.

In some cases users are seeing 500 errors for queries that take too long and Ecto kills the connection. Really, nothing should be taking that long. We need to do some profiling to figure out what's going wrong.

• database
• app

There are some nasty omissions and errors in the docs. This is an open ended issue (for now) to gather a list of them and knock them out.

• Need to explicitly list which filters/actions do not allow sorting or have other side effects that break other filters/actions; i.e. as_time_buckets doesn't allow user specified ordering.

Wire up Travis CI and make PRs conditional on testing.

There was a build error -- port 5432 cannot be used. We need to add a travis.exs config file and set the port to the database to something else and update the port config accordingly in .travis.yml.

I punted on this at first, but the question has been raised now: can we format observation data as GeoJSON?

The reason I didn't do it at first was because I have two competing ideas on how to do this.

Properties indexed by sensor path

{
  "data": [
    {
      "type": "Feature",
      "geometry": { ... },
      "properties": {
        "metsense.htu21d.temperature": {
          "2018-01-01T00:00:00": -4.2,
          "2018-01-01T00:00:30": -4.3,
          "2018-01-01T00:01:00": -4.1,
          "2018-01-01T00:01:30": -4.2
        },
        "metsense.htu21d.humidity": {
          "2018-01-01T00:00:00": 54.2,
          "2018-01-01T00:00:30": 54.3,
          "2018-01-01T00:01:00": 54.1,
          "2018-01-01T00:01:30": 54.2
        }
      }
    }
  ]
}

Properties indexed by timestamp

{
  "data": [
    {
      "type": "Feature",
      "geometry": { ... },
      "properties": {
        "2018-01-01T00:00:00": {
          "metsense.htu21d.temperature": -4.2,
          "metsense.htu21d.humidity": 54.2
        },
        "2018-01-01T00:00:30": {
          "metsense.htu21d.temperature": -4.3,
          "metsense.htu21d.humidity": 54.3
        },
        "2018-01-01T00:01:00": {
          "metsense.htu21d.temperature": -4.1,
          "metsense.htu21d.humidity": 54.1
        },
        "2018-01-01T00:01:30": {
          "metsense.htu21d.temperature": -4.2,
          "metsense.htu21d.humidity": 54.2
        }
      }
    }
  ]
}

Sentry Error: https://sentry.io/share/issue/55657a842d8848eb995cfd19760276ef/

Just because you can doesn't mean you should.

I want to list possible use cases for implementing web sockets for the API. Phoenix makes it easy to accomplish, but it's not entirely clear if it's worth the time and effort to build, test and maintain.

Please comment on this issue with ideas for uses and comments on proposed ideas.

This is a feature request. It would be helpful to have an endpoint that returns the latest observations for the nodes.

• /nodes/latest to get the latest for all nodes
• /nodes/:vsn/latest to get the latest for a specific node

In this sense, latest would be the latest observation by timestamp for the key {vsn, subsystem, sensor, param}. It may require creating a new table and setting up some triggers.