artsy / team-navigator

An internal HR product for Artsy's team
https://team.artsy.net
MIT License
62 stars 19 forks source link

@orta (cc @wrgoldstein + @sweir27): Image processing, detail view, tests and more #60

Closed craigspaeth closed 7 years ago

craigspaeth commented 8 years ago

Sorry for the large PR, I should have broken this up better but I was attacking things in a scatter-brained manner and ended up concurrently getting to this stopping point.

Quick reminder—this is our v2 branch of Team Navigator being used as an experimenting grounds for the React + GraphQL stack I demoed at Lunch & Learn currently code named "Mural". This PR includes a couple different additions, such as...

Image processing

For the sake of expirmenting, this uses sharp to embed an on-the-fly image processor inside the Koa app. It provides an endpoint /img/:id/:name.jpg that <img> tags point to. This endpoint will request the original high-res image from Dropbox, stream the raw contents of the jpg to sharp, sharp then resizes the image down to a 75x75px thumbnail, and we finally cache the thumbnail buffer in Node memory.

This is a silly experiment for the sake of seeing how implementing more server-side intense logic would look in this stack. Doing this, for one, has the caveat that storing JPEGs in Node memory could quickly hit Heroku's limit. However, ironically for this use case I believe it's a decent solution given that 1. sharp uses libvips which is really good at compressing our tiny thumbnails at ~4KB a piece 2. we're using streams that shouldn't hold on to a ton of memory during the processing 3. caching the file in the Node server means no need for network hops to a caching service, or adding complexity in syncing up with a CDN. So all in all I'm betting this doesn't cause enough of a memory issue to matter, and the end user experience is pretty decent given libvips compression + local caching 🙏

That said, in a serious app we'd just use Gemini 😛

Documentation and Tests

Adding a README.md, LICENSE, a suite of tests for some base MVC coverage. Model tests are pulling out the middleware functions, stubbing dependencies using a Babel plugin that adds rewire to imports (we have this in Metaphysics), and using Mocha, Sinon, and Should to round out the testing tools family. I'm also adding standard to npm test. I've outlined in the README how installing an in-IDE/text-editor linter and using mocha's --watch feature will be the most pleasant way to deal with testing/linting too.

Member detail view

Started the boilerplate for an individual member's view. Which still needs a lot of work. This just adds the controller functionality and renders their name in the sidebar. As pictured below.

cap

Finally

Phew! That's a fair bit to chew on. Let me know if you have any questions!

sweir27 commented 7 years ago

Mostly looked at the baobab/controllers/veact architecture here, but it seems so clean! I like that you can easily map out where all of the variables come from and are updated. Would be cool to see if prediction could use a similar thing ;)

craigspaeth commented 7 years ago

Updated Semaphore to Node 6 for a 💚 . Hopefully that's not a problem for the master branch.

sweir27 commented 7 years ago

👍 cool stuff!

orta commented 7 years ago

Oh nice, coool