ripgarpr / garpr

the revival of GarPR. may gar rest in RIP
17 stars 14 forks source link

[Infra] Angular 2 Upgrade, build tools #200

Open jiangtyd opened 6 years ago

jiangtyd commented 6 years ago

garpr's webapp is currently in a very non-standard state: we do have directories and separate js files, but instead of using any module system, we simply stick all the js files into index.html. This is not a sane practice. Furthermore, we have custom scripts like https://github.com/ripgarpr/garpr/blob/master/start.sh to start the webserver, when we should just use some kind of standardized build tool instead.

Also, there are some "cached page out of date" problems with the app when we redeploy, and using a build tool should help with that.

Proposal:

jschnei commented 6 years ago

So, fun fact: those scripts (i.e. start.sh and stop.sh) are not what we actually use in prod. prod is managed by a couple upstart jobs you can find here (I wrote a very quick readme at some point about this here). There's not really any reason you can't also run these jobs in Vagrant (I usually do, actually), just some people were used to using start.sh so I never added the upstart setup to the Vagrant scripts (you'll get port collisions if you do both this and try to run start.sh).

The actual serving (for both our webapp and api) is handled by Twisted Web Server. This seems to work pretty well so far, so unless there's a good reason I'm a bit hesitant to switch over to whatever node server is packaged with angular and deal with npm on the server-side (but there might be a good reason for this, e.g. the cache invalidation, I dunno).

But I completely agree with using some reasonable module system on the frontend (I know require.js used to be a thing, maybe it's now superceded by ES6 modules?). I also completely agree with upgrading to Angular 2 (maybe Angular 2 + Typescript?) and adding tests, but it's definitely an ambitious rewrite that would take some time. I think these things would go a long way to clearing up our frontend code debt.

jiangtyd commented 6 years ago

I think one of the big reasons to change to some node-based build system is that it will understand modules / browser caching / frontend performance much better than we can do with Twisted. Twisted seems fine for serving the Python REST API, though.

jschnei commented 6 years ago

Perhaps, but it looks like ng serve is not scaled for prod: https://github.com/angular/angular-cli/issues/5274? There's probably some solution here, though.

jiangtyd commented 6 years ago

Ah no, I was saying to use angular-cli to build; we should probably use nginx to serve the built files (built via angular-cli, I think?... need to do more research) in production.

BrandonCookeDev commented 6 years ago

So I suspect that after a few iterations of updates, myself and @JarrodBlanton will likely pair up to tackle this. Could possibly be a lot of hours in this. It may be worthwhile to do #197 before hand so we have a way to easily tack which refactored modules are still broken after being refactored.