acadeMe

Jungle Code Walkthrough

Covering the following

• Architecture diagram
• Key areas
  • State / Storage
  • Sandboxes (business stuff)
  • Views
    • Containers
    • Components
  • Services
  • Server side stuff
• The shitty sticks...

10,000ft view

Key areas - one bucket at a time

State using rxJS/ Store

A mutable store of data, categorised under domains that reflect our applications.

Send actions - All changes are triggered using rxJS actions. which are added to a queue to be handled.

Reduce the queue - The queue, runs reduce and all reducers we declare check for a matching name to determine if they are the intended recipient.

Store updates - subscribers trigger - All subscribers to that state pick up the changes because they're subscribed to them.

Sandboxes

Inspired by - http://blog.brecht.io/A-scalable-angular-architecture-part2/

It’s the only interface for our smart components (containers) to communicate with the rest of the application (i.e. the store and services).

It’s a facade that abstracts away specific business logic from our components.

View Layer

The high level blocks

App-shell is your root component... header, content, footer basics..

Common module is common to nearly all.... shared code stuff.

Articles, Authentication, Contact-us, Dashboard are all domains that reflect structure of the app..

Containers vs Components

Its just semantics

Containers are smart components, typically a page loaded by a router and always has access to at least one sandbox. 

Components are stupid, they only know how to take data @inputs, and delegate user inputs via @Outputs back out

Most of the time - containers encapsulate containers... exception to that rule is when a nested component gets a sandbox because it is less noise to do so... (tradeoff)

Services

But first a segue - Contentful story...

• Let's not user wordpress... Let's use a content-api like Contentful... easy to push data to mobiles later , supports locales... has a basic CMS we can extend...
• Contentful is bought and US starts its R&D / implementation of our backend
• ... after Paternity...
  • Contentful had some shortcomings on querying - but it has a graphQL implementation that solves them... and GraphQL is cool... lets do it
• ... Sometime around Oct/Nov...
  • cf-GraphQL does not support write access (Mutations) we need to use the original Write API.. Fuck! .. we're quite far into this now... will make it work.
• ... then in Dec ..
  • Contentful doesn't give us collection info e.g. total results via cf-graphql...
• Feels like contentful doesn't want to be used as a dynamic database tbh for things like comments, liking BUT we've been talking about implementing SocialEngine since Oct..

A very recent SLACK chat with CF guys

Round peg square hole? Probably..

Options

(I say #1 for now)

1. Leave it as is for now, but try to secure it by creating a proxy on the middleware tier to hide the CMA key at least

2. Build micro-services in house for 'likes', 'collections' and 'comments' and send the data there for speed instead.  Integration fun.

3. Rip out contentful altogether... likely the route the .NET guys will opt for.

back to services...

Write and Read

cma-service - The write service CRUD functionality for generic CF stuff.  We made cf-write-query-helper.service.ts to help with queries.

graphql-service - The readonly service uses graphql schema queries. Uses cf-read-query-helper.service.ts to help with query building

Common/Services*

* Some remain encapsulated in their respective modules e.g. authentication

Facades

For when something had both read and write requirements, a facade was made to encompass the common functionality and complexity.

Exception to the rule as always is when the process of writing was simple enough to use cma service directly...

e.g. 'User profile' and 'User preferences'.. but see profileprefs-sandbox.ts for where we  just use the cma-service directly for simplicity... inconsistent.. i know...

Common/Services

Processing..

This service is implemented by the graphql-service and cma-service and is just there to help with making it clear when the app is 'processing' something async.. we use this to reflect loading spinners on the UI etc...

Counters...

When we realised that cf-graphQL didn't send me 'total' for a collection e.g. here is 50 of 1020 possible results...  i had to write a query to pull totals for :

• likes
• comments
• article count

This might be deprecated after Emily updates cf-graphql to latest (this will take some reworking though)

Server Side

The new kids...

IIS Node Middleware

• Data read and write API between us and Contentful.
• A copy clones out inside your /server folder with 
  • npm run apollo:install
• Found here - https://stash.ngappsdev.com:8443/scm/ac/ng-academe-apollo.git
• Supported
  • Implements cf-graphQL and can pull data
  • Does a little zip download and unpack trick i wrote
• Unsupported so far
  • /entry - the proxy for the CMA API to hide CMA token in here, away from snoopers.
  • Needs to protect the /graphql endpoint using an auth token from RaRa..

RaRa

• Auth layer because client wants PII data in EU only.
• Managed by Bill (William Rood) and Emily 
  • Lives on US AWS server , needs moving to EU
• Found here - https://stash.ngappsdev.com:8443/projects/AC/repos/academe-user-api/browse
• Supported
  • Register
  • Login
  • Change password
  • Update user
• Unsupported so far
  • Emailing users on register / forgot password
  • Forgot password (blocked by emailing)

Shitty sticks

• Contentful
  • Not appropiate long term for Like, Collect and Commenting... should really move the responsibility away.
  • Security - Need to hide the tokens for the CMA.. inside the node layer
  • cf-GraphQL is in development, and doesn't support mutations.
• There might be more... but these are standout.