Epic: Project architecture

[VirtualDOMinic]

"Planning tech stack, software architecture etc"

Labelled as an epic, as this may go on to reference several other, smaller issues.

Time 4h - 1d

Please comment (if you'd like) any/all ideas about project architecture, db structure, tools, considerations (e.g accessibility), etc:

[VirtualDOMinic]

Rough notes on considerations

Accessibility:

• Kate has mentioned aiming for "AAA Accessibility". I agree, and think it would be important to aim for this site/app to be as accessible as possible, given that we expect people with a variety of disabilities to be using our app.
• Having read a bit about AAA Accessibility, it may be more realistic to aim for AA+ (i.e. at least cover all of AA) and have further improvements as stretch goals.
• Could be valuable to see if we can book in time with Tammy/Oli next week to get their input on our accessibility
• Also mentioned by Kate: using the gov.uk components

Packages/dependencies:

• Node with Express
• Do we need to use Handlebars? I'm open to suggestions...
• Testing?
• ES Lint?
• Hosting on Heroku? Open to that or Linode(?), DigitalOcean?
• AWS and Google Cloud Platform have free tiers, I believe, but can be difficult to use and get expensive beyond the free tier

Resources:

• Online tutorials (videos/articles)?
• Books?
• Packages with good documentation?

Database:

• Is it worth looking into ORMs (e.g. Sequelize)?
• Is it worth looking into benefits of noSQL (e.g. MongoDB) compared to SQL (e.g. PostgreSQL) for our requirements? Have generally heard positive things about PostgreSQL for most uses, but I'm no expert, and MongoDB is popular...

Collating our resources on Airtable

• I think Airtable would be a good place to store our resources for now. Can be sorted easily and treated a little like a Database. I'm not suggesting we use this for our production database though!
• Ideas for columns would be good. Currently thinking:
  Name | URL | Found Via | Relevant To | Specifically For | Notes
  "Relevant To" means who the resource is useful for (e.g. could be everyone), and "Specific For" means which ones are targeted by the resource (e.g. an online course might be relevant to everyone but not specifically for anyone)

Login and auth

• After struggling with using Passport and Express Sessions in week 8, I think we should either manually manage sessions or get some of Martin's expertise on these tools
• How are we going to handle email/password changes, recovery, etc?
• Should we start with just a database of resources and no login function, and have user registration as a stretch goal?
• Database design is going to be important: seem to be several different ways to manage a tag system, queries might get complicated

Building up the user's information on the front-end

• Currently thinking we could have an object that we populate with their "settings", that we then turn into a DB query
  Example (partial) object, which would start off with all values as false:

var userSelection = {
  age: true,
  ethnicity: false,
  gender: true,
  disabilities: false,
  ...
}

Also worth having another (or nested) object for the more specific settings?

var furtherDetails = {
  name: "Jane Doe",
  country: "United Kingdom",
  postcode: "SE0 0XX",
  age: 42,
  gender: "female",
  ...
}

Filtering/sorting and API

• For filtering once we've got all the user's results...
• Should these functions be front-end or back-end? If back-end, should they be DB queries of JS functions to sort?
• Are we essentially going to be making an API? If so, are there any Rest/GraphQL tutorials that cover the kind of thing we'll be looking at?

Inspiration:

• Art to ask other teams just before/after lunch what their current architecture thoughts/problems/solutions are?

More

• MVC architecture?
• Testing (but not TDD)? Which framework, and how do we prioritise this? Have specific times to make/run tests, or do as we go along?
• PWAs were mentioned by Lucy last week. I think it would be cool to attempt this, but have heard of people finding them a pain to create, or at least to debug. Stretch goal?

[sbinlondon]

BACKEND

• I suggest we stick with what we know on the foundational architecture: Node.js with Express
• In lieu of Handlebars, which I dislike the more I use it, I suggest we look into an alternative templating language like Pug*. Pug functions similarly to Handlebars but I believe is easier to write (no silly brackets and carats messing things up), has far more weekly downloads on NPM, great code coverage and a passing build on Travis, and seems to be more widely adopted - so there will be more resources for us to look into.
• We'll of course want our testing suite to be robust and used from the start: Supertest, Tape with Tap-spec, Codecov, Travis, and NYC.
• Further suggestions for middleware to start with: Body-parser, dotenv or env2 for environment variables.
• I'd be interested in looking at alternatives to Heroku, such as Netlify, Digital Ocean, and AWS to compare pros and cons and see if there is another platform that would be better to use. Or, if there is no clear advantage, it might be nice to use another one so that we become at least familiar with more than one. For example, AWS is widely used at the moment.
• I'm not very familiar with different database options but MongoDB (DaaS - database as a service) comes up quite a lot and I feel it would be worth looking into. I don't think we'd need a relational database for this project if we are just storing user info and we don't have to have it relating to anything else within the app. This will simplify our lives a lot.

FRONTEND

• Accessibility and design: Our app aims to help an incredibly wide audience, and actively seeks to help those with disabilities (mental, physical, etc). This means we should strive for AAA accessibility standards as set out by W3. GOV.UK is one of the only sites that meets this high standard, and they have components available for us to use to help reach these standards ourselves. Instead of creating our own design system, I'd suggest using the GOV.UK design system or even one from the Financial Times (also a highly accessible website) to save time and discussion.
• Popmotion Pure library for any fun UI animations or pizazz we might want to add to the app.
• I would be interested in learning and using SASS (pre-compiled CSS) because this is popular in the industry right now and I believe it would benefit us all to become familiar with it.

[MissArray]

Tech-access - Notes

General considerations

• Sample database:
  Have started one (see link) but happy to use an Airtable instead.
  https://docs.google.com/spreadsheets/d/1erZIoiyDLgFownWDZw8hAJtCoZdUt_Qiblxz9WdoBMk/edit#gid=0

• Updating the database. Providing links to events (e.g. meetups, workshops, courses) requires updating the database continuously. For the MVP, this shouldn't be a problem. For the 'real' thing, this raises the question of whether events should be updated manually by a human being or whether there's an automated way of doing this.
  APIs Aisha suggested using the Meetup API, but most events need to be hand-collected.
  Q: Is it a good idea / feasible in the available time to use a mixture of APIs and hand-entered events?

• User results If we're focusing on a mobile app, users are less likely to want to print out their results directly, but may well want to get their results e-mailed to them in a usable form (e.g. clickable links; a PDF). So maybe we could/should integrate that ability and make it available to all users, without requiring them to make an account?

More technical considerations

• App purpose should be clear on the splash screen

• A longer explanation and instructions on the 2nd screen

• Invite users to save their preferences (i.e. sign up / create a profile) or carry on as guests on the 3rd screen, before they launch their search?

• Topic tags. Perhaps start with noting down as many different (relevant!) topic categories as we can think of, then iterate & merge until we end up with a number of tags that we can display on (ideally) one screen? That'll be a trade-off between breadth vs manageability.

• Search mode. One idea might be to ask users to click on all the personal characteristics/preferences that apply to them and all the topics that they're interested in getting info on, then translate that into a database query?

• Might be useful to look at alternatives to postgres. If we go for an alternative, I'd personally pick one that has decent documentation.

• The same applies to any other tool we use, i.e. choose something that is well-documented.

[sunuwars]

tech stack:
html5, CSS, Javascript
Server:Express, Node
Database: Psql
Testing: Tape, Coverage: nyc
Deployment: Heroku
eslint, Travis
figma, invision

[MissArray]

Mongo vs postgreSQL

Article on MongoDB vs postgreSQL: comparison of features; when to use either.
https://www.sisense.com/blog/postgres-vs-mongodb-for-storing-json-data/

Great gov.uk references posters for accessible web-design do's and dont's

https://accessibility.blog.gov.uk/2016/09/02/dos-and-donts-on-designing-for-accessibility/

Pros & cons of using CSS preprocessors, such as SASS

https://adamsilver.io/articles/the-disadvantages-of-css-preprocessors/

Survey on how widespread SASS & co. are (2016)

In a referenced survey: used in about 1 in 2 websites.
https://users.encs.concordia.ca/~nikolaos/publications/SANER_2016.pdf