Blocked UI when app is georouting long or complex paths

[clhenrick]

Noticing that the UI locks up and results in the app feeling "frozen" when routing over a long or complex path. This is due to JS's single threaded nature where a long running task in JS will block things like UI interactions and browser repaints. Ultimately it's important for the app to not appear "frozen" to users when after they request a long or complicated route and it's actually working.

Two solutions could be:

1. Moving the routing code to the Node backend

2. Using Web/Service Workers to run the routing code client side

Both solutions would allow for the app to not appear frozen / locked, allowing for the loading GIF to still appear to be spinning as well as for displaying additional text to the user if the routing is taking longer than say 5 or 10 seconds (e.g. "still working...").

@gregallensworth is going to look into integrating the routing with web workers and I'll be looking into moving the code to the Node.JS backend.

[clhenrick]

Noting that from our discussion on Slack today Greg and I determined that moving the geo-routing codebase to the server side would give us a more flexible solution, in turn resulting in an API.

This has at least several benefits over web workers in that it would 1. work with older browsers (such as Android devices from three years ago that don't support web workers and that are likely to still be around), and 2. having the ability to be extended to other applications, such as a native mobile applications if we decide to go that route in the future.

[clhenrick]

One consideration with moving the geo-routing code to the Node.JS backend is figuring out what the maximum number of concurrent calls the server on Heroku would be able to handle and if that would be sufficient. For example if 5, 10, 20, or 50 people requested a route (and of what type? short, medium, or long) around the same time, how efficient would the server be at handling those requests?

This is one benefit that web workers would have over the server, each request would instead be handled by the user's device resulting in less server overhead.

[clhenrick]

More follow up based on work done by @gregallensworth:

• Heroku unfortunately has a 30 second time out. This is a problem for doing the geo-routing server side as the longest trips may take slightly over 30s to complete.

• Ideally, doing the routing server side would be to move it to a worker dyno, but this would involve a lot more work and debugging, and we currently don't have the budget to implement it

• Another drawback to using web workers would be that older Android devices running the 4.1 OS would not be able to use them, and there are likely people still using this outdated operating system on their mobile devices. Having two separate codebases for handling routing client side would also bring us towards unrealistic code maintenance goals.

[clhenrick]

Attempted implementing the geo-routing server side as a worker using the node-worker-farm library, but still ran into Heroku's 30 second limit when attempting to get a route from Calais, ME to Key West, FL.

[clhenrick]

Latest update: using node-worker-farm with a combination of setInterval to send single bytes every several seconds will keep the request open and prevent Heroku from throwing an application error.

[danrademacher]

@clhenrick let's go ahead and deploy the fixed version of the app with the nonblocking method of handling searches.

[clhenrick]

sounds good, will do that today.

[clhenrick]

Merged the branch serverside-directions-worker-farm into master, but waiting to deploy to Heroku when it's not the end of a day on friday.

[clhenrick]

17c8f82f0092f3abf0d3c4fdf2fa94826ae4f473 fixed an issue with the geo-routing, and the code changes were deployed to Heroku.