Key Takeaways from QCON London 2018 – Tuesday
Enterprise Node.js Apps in 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.
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.
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
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
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.
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.
Scenario 3. Go is Awesome
- SDL first approach, makes everything very flexible, so supporting GO is merely a question of mapping differently
A story about how npm is evolving.
80% of npm users use it for frontend development.
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
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
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.
- stack based
- 4 type
- 67 instructions
- Garbage collection
- More complicated since they need a garbage collector
- 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
- Host bindings, threading, SIMD
- Java, C# become production ready
- Another wave of mobile, desktop and server side UI
- Heavyweight productivity tool. Photoshop, AutoCAD
- Native Android apps die out in favour off PWA running on webassembly
- Windows store moves to PWA/WASM
- A new DOM alternative emerges
Observable JS Apps
Deeply observe every component in the frontend.
On the backend we have:
- Error Monitoring
- Product Analysis
RAIL Performance Model (developers.google.com/wen/fundamentals/performance/rail
- 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
- Log aggregator
- Metric tools
- Error monitoring tools