Add support for real time GTFS feed #24
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds support for real time gtfs data. Set and env var for each data type endpoint. our data source is a touch rate limit of 60 reqs per hour so i had to build a cache into the solution right out of the gate. the results are cached for 60 seconds. If you set a CACHE_URL env var then they will go to the redis compat. cache server or they will just be cached in memory in the node process.
The responses are all pretty large (72KB, 560KB and 3.5 MB). I added the ability to filter by
tripid
androuteid
to the vehicle position api and the trip updates api. i skipped adding filters to the service alerts api because i dont know what is a useful way to filter them and the response is <100KB so 🤷 ...I dont like all the cache logic sprinkled through the controller code but i decided to try to write it all out here to make sure i understood the desired rules and figured we can come up with a more elegant implementation later. ideally some kind of decorator/middleware for the route that just like
@cache(60)
or something like that.I also cleaned up the docker-compose since i haven't touch this in a while.