Planning Discussion: for Web Developers

[bkatiemills]

Check out the original CSB Assistant (try putting in 50 and K where it says 'Select Mass and Element'), and let us know how you would build something like this. What stack would you choose for this? A few engineering features we want:

• good use of routes & query strings to capture state
• html templating
• simple 'databasing', preferably actually just some json or csv to do lookups from, that can be swapped out easily.
• bonus points for simplicity and low number of dependencies: most labs don't have an in-house web developer, so ease of maintenance by non-web-folks is especially important.

Off the top of my head, node+jade+express could do this pretty easily, or Ember or React (overkill?). On the other hand, @AdamGarnsworthy asked about C/C++ only server side stacks; we could do, but I've never personally tried that - any recommendations for useful libraries / frameworks there? Don't forget to point out your favorite testing framework for whatever stack you recommend!

[bkatiemills]

Check out the demo in /pydemo - this implements stateful routes and templates in about 30 lines of python with only one dependency (thanks flask).

If you have another suggestion, show us how it's done in a similar demo!

[AdamGarnsworthy]

I dont think a server is necessary at all, and therefore no maintenance or support required on a backend. A purely javascript implementation could easily be made to reproduce the functionality presently in the php version. I dont know if a pure javascript implementation could achieve the URL routes for result reproducibility though - thats a question.

[bkatiemills]

Routes get done server-side, as does most HTML templating. There are some client-side templating options, and I guess you could jam everything into a query string instead of a route if you really want a 100% client-side app - but this is likely going to add more code than it saves in the long run. Could go either way!

Edit: actually, it might be good to get really crafty and stuff stateful information into the url hash instead of the query string; this way we can manipulate it without causing unnecessary refreshes. I'll try a mustache-and-hash based solution this weekend, and see how this looks in practice.

[bkatiemills]

Alright, /jsdemo reproduces as closely as possible the behavior in /pydemo, with pretty much the expected results:

• jsdemo templates and 'routes' (via the URL hash) completely client side as desired; can even run it off of gh-pages, see demo.
• but, this is (IMO) a larger, more complicated pile of javascript in lieu of a small pile of python.

I think the choice boils down to what you would prefer to maintain: more complicated javascript+html with no special server, or simpler client side stuff + a simple python server. I think both techniques are viable & reasonable, it's up to you.

edit: (or, secret third option: another suggestion from any of the web developers reading this - let us know!)

[bkatiemills]

Pushed a new demo feature to pydemo - server side plot generation in python. Start the server and visit the demo url http://127.0.0.1:5000/K/50 - a bunch of plots are getting pulled in from the server now. What's really cool about this, is that we can also serve the figures directly; visit http://127.0.0.1:5000/plot.png to just get the plot response (of course we can add whatever variables to this in order to plot something actually interesting) - with this route, we can easily provide transmission current and acceptance plots as a service to any other web app we want to make.

The javascript equivalent to this would be to serve a small javascript library that generates these plots client side - we can make this as simple as possible, but it means that people will have to be able to cope with writing some javascript and manipulating the dom, instead of just getting handed a png.

Edit: server side plots thanks to this demo.

[bkatiemills]

Alright - here's that same demo built a third way, again all-client side, this time using ember.js. Check it out at http://griffincollaboration.github.io/beamCompanionExplorer/#/companion/K/54

This is a more professional framework than rolling our own with mustache.js + home-spun url hashes, but the price is development has to be done within the full ember toolchain - you can see the working environment in this branch, though it's not as complex as it first seems - the only thing anyone should ever have to touch is under /app on that branch, and even there most of the guts are in the router, templates, and data handling in the routes.

Edit: though, notice in routes we just slap a big blob of json onto the window object and suck the whole thing in, since without a backend we can't ask for a piece at a time. We might be able to improve this by serving static json and parsing it with a custom adpater - will look into it if we go the ember route.

[bkatiemills]

OK so - according to #4, it's almost time to lay down the basic engineering we want to pursue for this project; I've presented three possible options, and I'm planning to spend the 13th and 14th executing on these more fully - but first, I need @AdamGarnsworthy to choose the option most appropriate for GRIFFIN. To recap:

• JavaScript frontend + Python backend
  • Pros: Simplest code overall, easiest to maintain and modify, easiest to make reusable assets (ie api endpoints for serving plots to any application).
  • Cons: Need to maintain a server.
• Ember.js
  • Pros: Pure client side app; most infrastructure obfuscated behind ember infrastructure. Most robust & professional way to implement a client-side solution.
  • Cons: Need to install and understand ember toolchain in order to modify app - very sophisticated.
• homebrew client side (mustache.js + URL hashes)
  • Pros: Pure client side app with minimal dependencies.
  • Cons: Routing and templating infrastructure highly exposed & minimal, resulting in more JavaScript to maintain with less features (relative to ember).

I would recommend the python server option on the grounds of easiest maintenance for the most flexibility, but this does not satisfy requests for fully client-side logic. Any of these three options are reasonable choices - let me know and I'm happy to flesh out the project with any of them before the 15th.

[bkatiemills]

@AdamGarnsworthy - I'll be up at UBC Monday afternoon; if it's easier to figure this out in person, I can drop in to finalize this decision around 3.30 if you're available.

[AdamGarnsworthy]

Hi Bill, I'm away on vacation this week, over in Ontario, not checking work email. Back on Monday. I'm glad the contract all got sorted out before I left so that you can start getting paid. I dont think we have a desk for you immediately, sorry, so you will have to use one of the counting rooms initially. Probably we can find you a desk in a trailer when I am back.

You will need to re-take the safety video as it changed in February 2015. It takes about 45mins to watch and then do the quiz.

This side project for the CSB is not GRIFFIN, it is completely separate. I would like it to also be separate from me in the future. Because of this I do not want to maintain a server machine at the backend - this is most of my preference for an implementation which does not have a server program we need to execute on the server machine. My preference is just for a few files which we put onto a place that serves the webpage (equivalent to the trshare setup).

I would also like this project to wrap up by the end of September (2 weeks) so we can start on the GRIFFIN related things that I would really like to move forward in the next few months.

Good to have you on board back at TRIUMF Bill. Cheers Adam

On Sun, Sep 13, 2015 at 2:24 PM, Bill Mills notifications@github.com wrote:

@AdamGarnsworthy https://github.com/AdamGarnsworthy - I'll be up at UBC Monday afternoon; if it's easier to figure this out in person, I can drop in to finalize this decision around 3.30 if you're available.

— Reply to this email directly or view it on GitHub https://github.com/GRIFFINCollaboration/beamCompanionExplorer/issues/2#issuecomment-139918876 .

[bkatiemills]

Okay great, sounds good - we'll go with the lightweight client-side option then, no problem. I think we can pull this off this month, if I focus on it heavily for that time. Glad to be back!

[bkatiemills]

In order to implement this fully client-side, while trying to keep the codebase simple and easy to modify, I built a mini-framework I call Ultralight. This framework provides templating (via mustache.js) and stateful routes, without exposing that logic to the app proper.