Static vs non-static App [discuss]

[rufuspollock]

From @pwalsh:

Implementing as static (built) app vs. static (javascript) app

In standup discussion went to Jekyll/Pelican - static site generators.

I planned to implement the dashboard as a javascript application (of course, it would still have "static" elements, so it might still site inside Pelican/Jekyll anyway).

The user stories can be addressed in both ways. It is more an issue of maintenance, etc.

I (vastly) prefer a javascript app for the dashboard.

In contra to the Open Data Index site, which is essentially a "push once a year" thing, the spend dashboard will have to handle many more data updates, fairly consistently over time.

Pros/cons:

JS app pros

• Clear separation between data and code
• Do not need to redeploy app in order to update data
• Maintenance of data does not require developer/git-savvy user

  JS app cons

• Possibly increases development time
• Possibly makes it harder for designer to work on code without developer

  Static app pros

• No javascript required to get data, so pages are discoverable via search
• Possibly leverage existing OK resources for templates (Jeykll)

  Static app cons

• Have to deploy code in order to deploy new data!
  • Ongoing maintenance of data therefore includes a developer, or at least someone who can use git

[trickvi]

From a dashboard point of view:

Have to deploy code in order to deploy new data!

is a big killer.

[rufuspollock]

I'm not exactly clear perhaps what JS app vs non-app means.

For me the key things would be:

• Static site (so we get SEO) - though of course can have plenty of JS too
• No moving parts (i.e. flask web app etc) - i don't mind JS in frontend
• Store data statically (appreciate that means regular pushing but don't see this as a big burden given that that new data will come through running a fairly complex ETL pipeline - in which case having a final "push to github" stage is likely not a big imposition)

I should also clarify that I'm not expecting lots of source pages (i.e. for each source file) - just a page for each publisher (though need to think a bit more about that).

[pwalsh]

Ok so for merge main thing is code and data seperation. I realise I may not have been clear enough on that.

By js app I really just mean that all data will come in via xhr requests from somewhere else: unlike what we did for the Index site.

So, if you see my UI mocks too (which may help), I envisage:

• a static site (no web server)
• all data comes from somewhere else (eg: csv files on some object store or a different github pages site)
• the static site is a host for a js app:
  • xhr requests to get data
  • tables, graphs etc in javascript (react or angular or whatever)
• updating the site data is completely unrelated to updating/deploying this code (unlike Index)
• the reports themselves can fit in this pattern (as in UI mocks), or I could render the report html directly to object store, in which case those would be purely static pages linked to from the main js dashboard.

Does that make things clearer?

[pwalsh]

(Excuse spelling.... mobile)

[rufuspollock]

@pwalsh hmmm. I thought this site would have data and we wouldn't have main data elsewhere (other than perhaps some of the "source" analysis data ...).

But now you explain it does make me think. I have to say for e.g. publisher summaries etc i think there are advantages to having that data in site and it also allows for proper seo but maybe that does not matter.

[pwalsh]

Another very important point: mixing data and code (let's call that the "Index" approach), is not scalable in terms of user story 8, even if it is just publisher data. We want to be able to simply deploy the dashboard app, per user/organisation, with some simple config to hook it to data sources (list of publishers, etc.) and away we go. the user is then responsible for setting up data, etc. (Ideally.)

In any event, my suggestion is that I do it as I planned now for the current sprint, and then we'll have a working implementation on top of mock data by end of this sprint. This will give us a basis to discuss more specifics.

[pwalsh]

Closing this.