Keynote

TBD

For me, the main track for tuesday is about Javascript, Node, GraphQL and similar.

Enterprise Node.js Apps in 2018

https://qconlondon.com/london2018/presentation/enterprise-nodejs-apps-2018

A session a bit about this and that coming from a developer from Paypal.

Type checking is an important factor, use at least Flow or Typescript, use ESLint.

Example:

let str: string = someFunction(horse).. Flow would hiccup with an error.

I have already considered using Flow before when coding REACT so this just makes good sense.

Next up is some details on architecture of javascript linter. Linters can only think about one file at a time.

Flow looks at all your js files, finds types and relationships, makes a graph. This is used to compare every single js file and based on the graph it will give error messages and warnings .

Basically use :

  • Flow to do type checking
  • ESLint to  find all sorts of other errors
  • Prettier to maintain style

Debugging Node.js

Not many good tools for debugging node.js apps, but Chrome now supports debugging node.js, In Node 8 there is a new feature Inspector. That gives way more info on stack traces.

Don’t do inspection in production though. Inspector also have a Inspector.Session(). This is used so we can “record” debug information.

Error Handling Using Async/Await

Async Middleware Pattern is a pattern to make sure you catch errors the right places.

Client Side Monitoring

How do we get information on what happened in the client.

window.onerror -> send error data to backend, quite simple really.

There are tools like track.js.

One key  takeaway applies to all technology try to make code changes backward compatible and consider separating UI and server deploy.

Other key takeaways:

  • Use static analysis
  • Have a plan for debugging applications
  • Adopt a constant approach to error handling
  • Know how to access all of your logs
  • Don’t forget to monitor the client side app

Parallelising Product Development With GraphQL

https://qconlondon.com/london2018/presentation/parallelizing-product-development-graphql

To set the base an introduction to a standard application is made, dead simple: Database -> API -> UI

This session will be about GraphQL API and a UI Graph Client.

We don’t know which clients will use our data in the future. Here comes GraphQL and Schema definition.

Directives are the everything else of GraphQL.

Resolvers can resolve fields from objects and resolves the Directory

Context object lives throughout

After this some examples are walked through.

Scenario 1.Prisma

A GraphQL API with a binding to a MySQL database.

Prisma basically serves as a framework to make a binding between mysql and graphql, and deploy as both api and binding to local docker a prisma server or kubernetes cluster.

Scenario 2. Frontend

  • faker.js – to generate fake json data.
  • graphql-faker
  • Apollo

Scenario 3. Go is Awesome

  • SDL first approach, makes everything very flexible, so supporting GO is merely a question of mapping  differently

Reinventing npmjs.org

A story about how npm is evolving.

80% of npm users use it for frontend development.

  • yarn
  • webpack

So a changed focus towards frontend development and not only node.js.

What about Express. No it’s out. Spife instead.

Spife is a http framework with lots of features

  • routing
  • database
  • orm
  • monitoring
  • logging
  • metrics
  • authentication

Spife is Opinionated djavascript.

Design system will be based on React, having standard elements as components. For example a form field will be guaranteed to work also for handicapped persons. Useful alternatives, for example

Spiferack. A framework the at supports

  • Server-side rendering
    • Searchable content
    • Fast initial page renders
  • Code splitting
    • Automatic split per-route
    • spreads bundle loading evenly
  • Progressive enhancement
    • Enhances to XHR request when JS is enabled
    • Returns JSON response XHR request i received

WebAssembly and the death of javascript

https://qconlondon.com/london2018/presentation/webassembly-and-death-javascript

First a history about frontend, javascript has been around forever, but we use it different

Javascript is not only used for the actual code that lives in the browser, it is also used for transpiring, packaging, building etc

JavaScript is not an assembly language.

Javascript lifecycle is roughly like this :

Parse -> compile + optimize -> reoptimize -> execute -> garbage collection.

WASM is designed specifically to be compiled to run in the browser.

asm.js is like a virtual machine in the browser.

WebAssembly:

  • stack based
  • 4 type
  • 67 instructions

Coming features

  • Garbage collection
  • Threads

Language Support

  • C/C++
  • RUST
  • Java/C#
    • More complicated since they need a garbage collector
  • Javascript
    • Needs a GC and isn’t statically typed
    • AssemblyScript – Typescript to WebAssembly compiler, but awaiting GC before it can become more powerful

Crystal Ball says that WASM might be used for

  • RUST / C / C++ used in production
  • Webpack will integrate WASM
  • Java C# Typescript PoC’s
  • Native Node Modules, node 8+ supports wasm
  • GC SUpport

2019:

  • Host bindings, threading, SIMD
  • Java, C# become production ready
  • Another wave of mobile, desktop and server side UI
  • Heavyweight productivity tool. Photoshop, AutoCAD

2020+

  • Javascript will compile directly to WASM
  • Native Android apps die out in favour off PWA running on webassembly
  • Windows store moves to PWA/WASM
  • A new DOM alternative emerges
  • Javascript’s monopoly will be lost

Observable JS Apps

https://qconlondon.com/london2018/presentation/observable-js-apps

Deeply observe every component in the frontend.

On the backend  we have:

  • Metrics
  • Events
    • Logs
    • Traces
    • Error Monitoring
  • Product Analysis

RAIL Performance Model (developers.google.com/wen/fundamentals/performance/rail

  • Response
  • Animation
  • Idle
  • Load

Instrumentation Code

  • Use Boomerang

When to fire events

  • On page load
  • On SPA navigation ( for example in the React Router )
  • On significant user actions ( conversions, form submissions )
  • On page unload

On page load collect info about browser and capabilities

On SPA Navigation collect info about user route ms

On User event log what happens

On Page unload memory info, performance, javascript errors, window open duration in secon

Tool choices:

  • Log aggregator
  • Metric tools
  • Error monitoring tools