@ryanchenkie
GraphQL Dev Rel at Prisma
@ryanchenkie
@prisma
function add(num1, num2) {
return num1 + num2;
}
add(1, "foo");
@ryanchenkie
@prisma
function add(num1: number, num2: number) {
return num1 + num2;
}
add(1, "foo"); // compilation error
@ryanchenkie
@prisma
How much collective time have we lost to type issues?
Author time
Runtime
@ryanchenkie
@prisma
@xjamundx
Jamund Ferguson
@ryanchenkie
@prisma
"We had no idea why or where our apps were failing"
@ryanchenkie
@prisma
Requirements change over time
We prototype and will "fix it later"
As team size grows, so does the surface area for invalid code use
@ryanchenkie
@prisma
We want to move quickly, leading to:
Lack of documentation
Lack of good abstractions
Lack of solid knowledge of our own code
@ryanchenkie
@prisma
Over time, requirements change, leading to:
Bad abstractions surfacing
Brittle code
Brittle data models
@ryanchenkie
@prisma
As teams grow, so too does the possibility for:
Code misuse
Repeated code that does the same thing
Diffuse domain knowledge
One Way to Help:
@ryanchenkie
@prisma
@ryanchenkie
@prisma
Typical
Front End
Backend
API Access
Less Typical
Database Access
@ryanchenkie
@prisma
import React from 'react';
interface UserProps {
name: string;
email: string;
}
const User: React.FC = (props: UserProps) => {
return (
<div>
<p>{props.name}</p>
<p>{props.email}</p>
</div>
);
};
@ryanchenkie
@prisma
interface User {
name: string;
email: string;
}
function getUser(): User {
return {
name: 'John Doe',
email: 'john@doe.com'
}
}
@ryanchenkie
@prisma
type User {
name: String!
email: String!
}
type Query {
users: [User]
}
@ryanchenkie
@prisma
model User {
name String
email String
}
Managing Type Safety is a Pain
@ryanchenkie
@prisma
There's tooling that makes it easier, including Prisma
@ryanchenkie
@prisma
@ryanchenkie
@prisma
@ryanchenkie
bit.ly/fullstack-typescript