simplify API and allow running via docker-compose and GKE #46
Conversation
…and point reliabilities; use seconds instead of milliseconds; add new vehicle fields for gtfs-realtime providers; rename some fields and type names; remove unused code
src/resolvers.js
Outdated
| const { agency, routes } = params; | ||
|
|
||
| let { startTime, endTime, pointReliabilities } = params; | ||
| let { startTime, endTime } = params; | ||
|
|
||
| // times are returned as strings because GraphQL numbers are only 32-bit | ||
| // https://github.com/graphql/graphql-js/issues/292 |
There was a problem hiding this comment.
Since it's being changed to seconds epoch, could timestamp, startTime, and endTime be Int instead? I only used String as a workaround for the timestamp being in milliseconds as JavaScript's Date library uses milliseconds epoch (and the codebase was all in js too).
There was a problem hiding this comment.
I kept timestamps as String to avoid the Year 2038 problem, since GraphQL would throw an error if a timestamp is greater than or equal to 2147483648 (Tuesday, January 19, 2038 3:14:08 AM GMT), in case this code stays around for another 18 years and GraphQL still only allows 32 bit signed ints, although I don't feel strongly about this if you'd still prefer to use Int.
There was a problem hiding this comment.
It still seems less worse than using strings for timestamps in seconds, and would avoid the need for casting it to Int (for metrics-mvp and possibly other users) so that's why I prefer it.
It looks like the best solution is to make a scalar (https://www.apollographql.com/docs/graphql-tools/scalars/) for either Long or an Epoch type - but it's definitely not worth doing now.
Also adding a scalar wouldn't break metrics-mvp as python ints are 24-bit, so it could always be done in the future. And Int would use less space than strings when making API calls but that's probably negligible.
There was a problem hiding this comment.
Thanks for the information about scalars - I just implemented it and it seems to work well.
| } | ||
| }); | ||
| }); | ||
| }))); | ||
| } | ||
|
|
||
| function getTimestamp(key) { | ||
| var keyParts = key.split('-'); | ||
| return Math.floor(Number(keyParts[keyParts.length - 1].split('.json')[0])/1000); |
| if (timestamp >= startEpoch && timestamp < endEpoch && !timestampsMap[timestamp]) { | ||
| timestampsMap[timestamp] = true; | ||
| res.push(key); | ||
| } |
There was a problem hiding this comment.
Thanks for fixing this as well!
…stamp intead of string while avoiding year 2038 problem
|
I also changed the |
There was a problem hiding this comment.
Thanks for adding bigint - it's less complex/more cleaner than I thought it'd be so thanks for looking into that. Also, renaming to agencyId makes sense, especially given the changes in metrics-mvp (Can't wait to see other agencies being supported there!). Everything else looks good to me.
This PR simplifies tryn-api so that it only returns vehicle state from S3 and no longer returns route configuration, so that it doesn't need code to handle different transit data providers.
Since this is a change that would break existing clients, the PR includes several other schema changes at the same time:
trynStatefield renamed tostate,pointReliabilitiesparameter removedendTimeparameter was inclusive, now is exclusiveRouteStatetype,vtimefield renamed totimestampRoutetype renamed toRouteHistory,ridfield renamed torouteId,routeStatesrenamed tostatesVehicletype renamed toVehicleState, and addedtripId,stopIndex, andstatusfields to provide data collected from GTFS-realtime providersTrynStatetype renamed toAgencyState,idandpointReliabilitiesfields removedIt also no longer needs config files or the Restbus API.
To avoid breaking existing clients, this should be deployed to new URL while the existing service continues running the old code at the old URL. Then clients should be updated to use the new API at the new URL, and once everyone is using the new API the old service can be shut down.
This also fixes an issue with agency names containing dashes, and avoids returning data outside the requested time range that is within the same minute as the start time or end time.
It also now uses the same approach as metrics-mvp and orion for running with docker-compose in development and GKE in production, with a cloudbuild.yaml script that can be configured with Google Cloud Build to automatically deploy to production when new code is merged into the master branch.