List view

• Server Error Handling

  We need a standardized method for handling errors. This milestone also captures likely areas of error which need additional consideration.

  No due date

  •2/4 issues closed
  50% complete2 open2 closed

• Server Data Quality

  All data listed in https://docs.google.com/spreadsheets/d/1ygASWff6FF5nfwNdA88KGcotJM6jDepFKSyvybwVLmg/edit?usp=share_link should be implemented and working as expected.

  No due date

  •21/28 issues closed
  75% complete7 open21 closed

• Server Secrets Implementation

  GitHub has the ability to store secrets which can be used during deployment or development. We should store API keys and other secrets in this feature.

  No due date

  •1/1 issues closed
  100% complete0 open1 closed

• Backup Source for Ferry Tempo Data

  In the event that WSDOT's APIs are not available, we need to implement a resiliency plan. This milestone should provide an alternative method for fetching the data required for Ferry Tempo client operations.

  No due date

  •1/1 issues closed
  100% complete0 open1 closed

• Server Debug Logging

  Once our server is deployed, we will need to capture logs to help with debugging.

  No due date
  0% complete0 open0 closed

• Server API Key

  In order to ensure that the FTServer is only being accessed by FTClients, we need to include an API key for calling the service. This milestone captures the work of adding that API key configuration to the server and checking it in all calls coming into our service.

  No due date

  •0/1 issues closed
  0% complete1 open0 closed

• Server Debug Page

  Implement a human-readable debugging page to help figure out issues with the FT data.

  No due date

  •1/6 issues closed
  16% complete5 open1 closed

• Port Go Server

  To migrate from the V1 Ferry Tempo implementation, we need to port the logic in https://github.com/pietroglyph/fow/tree/master/fow-server to the new NodeJS service.

  No due date

  •2/2 issues closed
  100% complete0 open2 closed