Reports screen is broken in local dev server

[straight-shoota]

After following the installation instructions, when you go to the Reports screen (/dashboards/nndd), the main content of the page shows an iframe with a connection error ("No connection to port 9000").

[straight-shoota]

So the reports screen is provided by an embedded client-side application, that integrates with the CDx API. The source code for it is at: https://github.com/instedd/notifiable-diseases

It contains instructions and even a Dockerfile that's supposed to provide a dev environment. But it doesn't build anymore. The codebase hasn't been updated in 6 years. Packages are not locked, so newer versions of packages will be installed which are not compatible with other components anymore. I'll try to beat it around a bit and see if I can bend it to my will. But I have little experience with JS build systems, so not sure if I can get anywhere. But it still works in staging, so there seems to be some way to get it to build. Or maybe the staging image doesn't get rebuilt and it's just not changed for years. At least the staging environment provides a working application. Although I don't have much of a clue how it's supposed to work or what it actually does. The UI seems glitchy and unintuitive. It looks nothing like the designs at https://projects.invisionapp.com/d/main#/console/4103589/126181684/preview ff.

Anyways, the codebase is just really old. It's all written in CoffeeScript and uses angular 1. Packages are installed via bower. That's all pretty much obsolete (maybe not CoffeeScript, it could still be an - opinionated - choice, but it's lost much of its drive due to TypeScript, ES6 etc.). All other dependencies as outdated well. I expect a long way ahead of us to get this up to speed. This might be a good opportunity to consider whether it would actually be easier to just rewrite the entire thing with tools of the modern day. Or if the old behaviour is actually still wanted or not.

[diegoliberman]

Awesome analysis. I think with this picture we can already start thinking on keeping us away from that part of CDx, at least for this year. So, I would build the reports that we need in a separated page, with the tools that we choose.

@straight-shoota I wouldn't continue digging here. Let's move on to the next thing. Thanks!

PD: @nditada you might want to say something here.

[ysbaddaden]

@matiasgarciaisaia I assume we didn't change the image for years?

If we can download it, we can run a shell in it, and extract/list the installed NPM packages, and at least limit the direct dependencies.

Note: yeah, CoffeeScript is obsolete these days.

[matiasgarciaisaia]

cdx-stg.instedd.org is a new environment I've set up when we resumed CDx work with RADx. So I know for sure it doesn't include any arcane incantation to make it work with Notifiable Diseases (friends call it NNDD).

What is actually new is the Dockerfile-dev, which has some commented out lines regarding the installation of NNDD (because we created it from the productive one, but for development we may want to have a development version of NNDD). And since we were in a bit of a hurry and not caring about NNDD that much, we may have overlooked it.

This is the release of NNDD that we're using in staging/production. And this is the TravisCI log for that build. So there we have at least one well-known, working set of dependencies that allowed to build the thing. I guess that helps?

I have a local clone of the project with dependencies installed, too. Not sure if they build (I don't have Node 0.12 anymore 🙃) but we can assume they worked at some point in time. Let me know if you need me to try to extract the versions from there.

I totally agree on the "all of this is probably obsolete" part.

---

Edit: Here's the build's raw log, just in case: https://api.travis-ci.org/v3/job/113182210/log.txt

[ysbaddaden]

@matiasgarciaisaia Yeah, that's the distribution tarball, we can't use it for development.

We can generate a yarn.lock from installed packages in the node_modules folder with yarn import. All we need is a node_modules folder! The bower dependencies are constrained, but the bower_components folder wouldn't hurt :)

[matiasgarciaisaia]

Here's a yarn.lock just generated with yarn import using Yarn 1.22.4.

yarn.lock.txt

[ysbaddaden]

We can't use Yarn with NodeJS v0.12. The oldest release (0.14) requires NodeJS v6. Trying to install dependencies in a NodeJS 6 image fails while trying to install some dependencies (e.g. jpegtran-bin).

We can however build a docker image from the current Dockerfile, replacing the global grunt-cli with grunt-cli@1.2.0 (compatible with Node 0.12) and use @matiasgarciaisaia's node_modules and bower_components folders.

Then we can run grunt build --force and we can build the app. This will be enough if we need to make some adjustements to NNDD. We an always build offline and upload the build manually.

If we need to maintain NNDD actively, it will likely prove much simpler to just redo the build system from scratch, rather than trying to fix/upgrade the current one.

[ysbaddaden]

Or maybe integrate it into CDx directly.

[matiasgarciaisaia]

We used NNDD in another, non-CDx project back when we developed it. I'm not sure if there's any chance we'll ever use it that way, but I guess it'd be nice to keep it independent unless it's way more easier than merging it back.

Creating a Docker-based build system shouldn't be that hard, I guess.