User:Pablo Grass (WMDE)/conferences/IJS2019 Munich/day4

Day 4 of a JavaScript conference in Munich.

Web applications of the future with TypeScript and GraphQL, Roy Derks @gethackteam, City of Amsterdam

GraphQL standard for APIs, like REST, not a framework or specific implementation
queries indicating relevant fields can conveniently reduce payload size
- especially relevant on e.g. phones
just "one enpoint for all datypes"
mentions graphiql as alternative for e.g. postman
says github REST API internally depends on their graphql systems, uses them as an alternative representation
shows graphql backend refusing a payload (string instead of number) if it violates the schema
compares graphql and typescript type systems
- uses the chance to declare a price field as float
- in graphql one declares fields as required - opposed to optional in typescript
uses appollo, schema is stored in json file
shows '@graphql-codegen/cli'
- allows to create synergies between typescript and graphql - creating consistent types
- in practice generates typescript from graphql schema
- even works if the schema is remote (URL)
- "good for set up and to ensure they stay in sync"
shows https://graphql-code-generator.com/#live-demo to generate a TS frontend application, incl high level components based on a wizard
advocates starting to migrate legacy JS code bases to be typed (maybe just some components, functions for a start) gradually but start today
QA
- apollo best to get started: yes and no. quick initial results, later can become restricting. also a single vendor which has some risks associated
- how to set up a graphql backend: just express, do the wiring yourself
- some say graphql is dead: it's not

Learnings

'@graphql-codegen/cli' is a thing

Carving Microservices out of the Monolith with Domain Storytelling, Henning Schwentner @hschwentner, WPS – Workplace Solutions

Domain Storytelling - a collaborative modeling method
- users (domain experts) and devs work together
- apply the cavemen's instinct to tell a story near the camp fire to modern challenges
- don't paint the cave wall but a white board - but still spark a fire
example: "sea port" of Hamburg not located by the sea
- how do we implement a software to simulate ships moving up and down the river (limited depth and width)
- explains former (manual) approach: sounding ship -> cartographer -> depth map -> navigating officer -> route + ship silhouette (incl dicussions with captain)
bring together (in one room) the right people and let information flow
- people: developers (who build it) and "chuck norris" domain expert
- domain expert tells story, avoid proxies (e.g. bosses explaining ideal or former realities)
- devs draw what they understood ("active listening" but not by repeating verbally but drawing it out)
- domain expert confirms if understood correctly
- focus on concrete stories rather than abstract concepts
building blocks
- actor (e.g. person, group, with a tie or hat to depict a boss)
- work object (e.g. a car, a sounding chart)
- activity
- sequence number (to track time inside the story)
by design there is no conditionals - only tell one story at a time (don't explain that Hänsel and Gretel would have stayed at home and the witch would not have caught them in case of rain)
actors are mentioned only once (human centered) but work object can occure repeatedly, different activities can be applied to them
lay out the canvas
- modeling space
- preconditions & assumptions (e.g. enough water in the harbour to land ships)
- annotations, variations, purpose
Peter Hruschka "3 good examples better than one bad abstraction"
next job: find subdomains - "if something is big, cut it down into pieces"
don't separate people, though - subdomains and models instead
in the "sea port" example: separate creation of the depth map from when it is applied
in software projects we want to find these sub domains and create bounded contexts, isolated programs, independent systems, out of them
- creates resillience, one system can stay up (e.g. work with the old depth map) while the other is down (e.g. a new depth map is being created)
indicators for bounded context
- one-way information flow (e.g. only from the depth map to the navigator)
- different use of the same thing (e.g. the map being used for different purposes)
- difference in language (e.g. ??)
- different triggers (e.g. more than one ship measuring depths)
- ask the domain experts, they will have ideas
don't build the model you assume the world is, but build it the way it is
most of what was said works best when applied in the green field
reality in brownfield project "one big ball of mud" looks much different usually
- identify "how should it be" (what would we do if we did it all over?) - domain story telling, event storming
- identify "how it is currently" (as-is context map)
- identify "how to move from the 'is' to the 'ideal'" - the first two steps need to be done first!
start with "supporting" functionality
the consultant consults us to use consulting and not go into this assignment alone, bring someone who has done this before
live demo: whiteboard modeling "traveling to conference by train"
- people add their thoughts
- along the way we collect assumptions: buy at train station, train is on time, we did not reserve a seat, direct connection
- along the way we document variations: buy online, with reservation, train breaks down, ...
- along the way we document related processes: time planning, travel expenses
- interestingly left out the actors at first, explains this
level of detail at which we model depends - high level first, then dive in
mentions https://github.com/WPS/domain-story-modeler built by working students at his company
mentions https://leasingninja.github.io/
Q&A
- "shared kernel": start without and accept some redundancy

Learnings

many a keyword from above

Building effective design systems in Vue, React or whatever, Sanne Peters @sanstreamed, Senior Front-end Architect, Bankai UX Design

how to get everyone on board, communication, ... - it's not about the framework
sees architecture as a dedicated role, should not be done implicitly
design systems are communication and collaboration system
- components and colors is but one aspect
many stakeholders and everyone get worth out of a design system at a slighly different angle
3 steps
- work together (own collaboratively, in "a common language")
- structure - "allow yourself to think less and free some room for creativity"
- ??
new, recent things often don't have universally understood name
use the same terms for the same thing - involve each other in the decision making for the name
- usually starts a conversation in which detailed behavior, unclarities are surfaced
close collaboration may loosen up what a role entails and what it doesn't
design tokens define the most basic values
use names for design tokens that make sense for "most people" - e.g. "CTA color rather than primary color"
create hierarchies - "meaning on a higher level"
analogies (atom, molecules, ...) used in the industry are very abstract and don't necessarily help mutual understanding
advocates to use analogies of more tangible things (brick, house, street plan) - does not quite prevent slightly different understandings though?!
composing components, not building them is the goal
work on components is iterative work and should be seen as a creative process ("digital artist")
designers are not the owner of the design; co-owners at max
teach the designer e.g. what a spacing system means to you as dev - they don't think in paddings in margins
most often animations and transitions are not defined - ask to clarify
naming is hard - name by "what it [actually] does" rather than by "what it [currently] does", every day words
mentions vue js guide on naming things (where?)
documentation is an investment (with a ROI eventually) - you'll never have to explain it again
mentions a (proprietary "trademarked") tool "gitsumy" (or some such) they build as alternative to storybook
system allows you to be creative quick "within the box" and aligned in collaboration, you can still go outside the box when needed
Q&A
- why styleguidist?: storybook is too dev-oriented, she prefers simplicity of markdowns which designers can influence
- how to couple "real code" to the documentation (if in different files)?: <unintelligible>

todo

vue js guide on naming things (where?)

Are you being served? — exploring a serverless web, Phil Hawksworth @philhawksworth, Netlify

starts with a joke, compares server-less with "wireless" charging which still requires you to plug in the wired charging station
mindset: write code rather than keeping servers alive - where do we focus our efforts
"functions as a service"
introduces "jamstack" - javascript, APIs, (pre-rendered) markup ... without a server rendering
references Aaron Schwartz "bake, don't fry"
candidates for static generation: documentation, ...
shows his own blog, which (via netlify) uses "build hooks" hooked up to e.g. twitter to rebuild which pulls latest tweets
shows how he built a "static clock" which deploys every minute (plus uses GTM to even go the right time zone) - "don't do this"
reasons for pre-rendering (among others)
- put distance between user and complexity, as far as possible
- reduces attack surface
- only one "cache" to purge
temptation of course could be to port a traditional application to serverless
example https://vlolly.net/
- pre-generated pages, even for user generated content
- data in db
- "instant" access to db
shows trigger-based static generation and falling back to serverless while it is still building
advocates a shift: "static first" (everything is prerendered) instead of introducing cache layers and still have something static in the back
simplifying is not dumbing-down - let's us focus on what is really important

Learnings

netlify is a hosting provider

Progressive React apps, Sebastian Springer, MaibornWolff GmbH

how to put PWA into real-world (react) web apps
service workers are one important part
among others https://www.npmjs.com/package/@vue/cli-plugin-pwa is a thing
(re)iterating PWA characteristics
mentions suggested break points for material.io https://material.io/design/layout/responsive-layout-grid.html#breakpoints
"service worker for offline capability must be built in from day 1, can hardly be bolted on"
annoyance: service workers do not work with http, dev needs to be https, too
explains different strategies
- interestingly picks static assets (images) as example
mentions IndexedDB (which has a horrible interface) and how it can help dealing with API information and caching
mentions https://www.npmjs.com/package/dexie and how it can be used to access IndexedDB
mentions PouchDB with may help with conflict resolution on saving
"a lot of logic in the service worker layer can complicate things - hard to test, ..."
advocates using redux (standardized information flow)
- server communication becomes a side effect of an observe behavior
- implement one layer where "offline" capability is taken care of, not spread around the application
advocates carefully informing the user before trying to install the application (browser prompt) or send them notifications
mentions lighthouse in PWA mode and test drives it on mobile.twitter.com
Q&A
- indexDB and data protection: is a challenge, as available for all users, encryption is an option but good question

Learnings

chrome://serviceworker-internals/
https://serviceworke.rs/ service worker "cook book" by mozilla
https://www.npmjs.com/package/dexie wrapper library for indexedDB

Profiling JavaScript Apps like a pro – even with Angular, Gil Fink @gilfink, sparXys

1st suggestion: do it during the development process, not retroactively
for rendering 1 frame there is about 10ms (60fps + overhead)
explains the "pixel pipeline"
- JS
- style (individual elements)
- layout (position of elements on page)
- paint (fill pixels)
- composite (overlapping of elements => GPU)
"reflows" are a re-run of the "pixel pipeline" when your browser deems them fit
"repaint" re-run of the "pixel pipeline" without the "layout" part
changes without "layout" and "paint" are desirable
suggests the RAIL model: response (process events in <50ms), animation (produce a frame in 10ms), idle (maximize idle time), load ("deliver content in under 5s")
this talk will largely be about the "response" part
shows dev tools and that the performance tab actually has a "paint profiler" tick box (not part of the talk, though)
puts focus on time line and the
steps of profiling
- establish a base line (in incognito to disable extensions, ...)
- collect data by running profiler
- analyze results
- tune app
- rinse and repeat
shows "Bottom-Up" tab to identify _own_ scripts which consume bulk of the run time
example: movie list implemented in angular. 3500 movies shown with a component with "default change detection"
- switching "change detection to onPush" (of title which is a prop, I think) makes all our problems go away
reasons for leaks
- (accidental) global variables
- forgotten timers or callbacks
- out of DOM references to elements (no garbage collection then)
- closures (variables will stay alive after it finished)
mentions https://www.twilio.com/blog/prevent-memory-leaks-angular-observable-ngondestroy
reminds to clean up after yourself in SPAs especially for observers (e.g. via onDestroy)
"performance monitor" recommended to look at run time and impact of user behavior on resource consumption
promotes "pure pipes" for deterministic behavior

todo

vue and "change detection" (for "dumb components" which only receive changes via props)?
does the "pure" concept exist in vue?