Note: this article will not make much sense unless you know the basics of GraphQL, an awesome technology we use at Slite. We recommend you get a brief understanding of it before going forward. Here are some resources.
What are n+1 requests?
n+1 requests are the most obvious optimisation issue one might encounter when writing a GraphQL backend. It’s easy to illustrate with a simple relation: let’s say you have a User type which has a relation to an Address type.
type User {
id: ID
address: Address
}type Address {
id: ID
streetName: String
city: String
}
Now, let’s assume you have a simple query returning a list of users, a client might do this…
If you’re using react, chances are that you are using the whole babel + jsx + webpack stack (and you’re goddamn’ right).
Your components files, the 1627219 of them, look like:
import React from 'react'export function YourComponent() {
return <span>Hello, I do nothing</span>
}
Now here is the protip that will save a lot of time, in your webpack.config.js:
plugins: [
new webpack.ProvidePlugin({
React: 'react',
}),
],This lets you omit the import React from ‘react’ line in all of your component files and this will work just as well:
export function YourComponent() {
return <span>Hello, I do nothing</span>
}Bonus: As you don’t import React directly anymore, this prevents eslint from bugging you with `’React’ is defined but never used no-unused-vars`.
TL;DR:
This article explains how to make your unit test setup and workflow as simple as possible (assuming you use babel).
- code and tests just next to each other in the same file
- tests run in the browser every time you build your app, just like regular code
- wipe tests code automatically for production builds
- use a Chrome Extension to control execution and improve display of results
- Continuous Integration mode comes for free
Checkout this example or watch me talk about it at #londonreact (slides).
Motivations
Current developer experience around testing sucks.
Tooling is too bulky and workflow is unappealing.
The test runners we use are big systems that are really hard to integrate properly in our already complex toolchains. …
Rationale
EDIT: I just released rm_local_modules, a really simple module best used as a npm preinstall script so you can quickly update (delete + reinstall) all your local modules simply. Problem is, npm 3 preinstall is broken.
Most large javascript application built using npm modules have the same problem: tons of javascript files stored in deeply nested folders.
You will definitely end up with ugly require such as
var User = require(‘../../../../models/User’);This sucks. Relative requires do not scale well. What you want instead is:
var User = require(‘app-models’).User;Hey but that means I need to publish my module, use private modules or host it on a separate git repo?! …
About
