In this post I cover a relatively specific but common problem in modern
web applications, form validation. I go through how you can set up a system to
use your existing front-end form validation to validate your GraphQL
mutations/queries. Meaning that if a user was to send a GraphQL query direct to
your API, they'd run into the exact same business logic as is implemented in
your form, and you don't need to write it twice!

As a side-effect of how specific this post is, you'll need to have an
understanding of the following:

- GraphQL
- graphql-shield
- yup

## Building Your Form Schema

We'll be building a simple todo input that is validated by it's
length and limited to 100 characters. Our yup schema could look as follows:

```js
const CreateUpdateTodoItem = yup.object().shape({
  id: yup.number().nullable(),
  message: yup
    .string()
    .max(100, "You can enter a maximum of 100 characters")
    .required("Please enter a message")
});
```

Right now you might write this logic twice, once in a yup schema on the
front-end, and perhaps in your resolver or model logic on the backend. This
becomes pretty hectic when your form logic becomes complex and needs to be
maintained by others.

**Tip:** If you are using React, I highly recommend using Formik, it works
seamlessly with yup.

## Your Backend Implementation

Adding to your GraphQL validation is as simple as your existing front-end
implementation, you'll write a new graphql-shield rule for each query/mutation
that you want validated. For example, in our case:

```js
import { inputRule, shield } from "graphql-shield";

const createUpdateTodoItemRule = inputRule(() => CreateUpdateTodoItem);

const schema = applyMiddleware(
  makeExecutableSchema({ /* ... */ }),
  shield({ Mutation: { createUpdateTodoItem: createUpdateTodoItemRule } })
);
```

## Things To Note

- The schema you write for end-to-end validation may need to differ slightly
from the schema you use only on the front-end. The reason being that quite often
your form fields don't map 1-2-1 to your GraphQL arguments. The solution for
this is to write the validation as if it were to be used only on the backend,
and transform the input from your form using:
```js
CreateUpdateTodoItem.transform(formInput => { /* validated object */ });
```

- You can share code between applications in more ways than one, however I'd
always recommend using Yarn Workspaces to manage the dependencies of your
front-end, back-end and shared code, all in one monorepo. You could alternatively
publish a private npm package.

## Conclusion

Although this may be overkill for some projects, in production apps one of
the most common security vulnerabilities is the lack of back-end input
validation. Making it easier for yourself by reusing the code will result in a
more secure system.

This is just one solution with some relatively specific tools, I hope this at least helps
kickstart your thinking into how you might implement in your own project!

Building End-To-End Form Validation with Yup, graphql-shield and GraphQL

Until recently CSS was a common moan within web development, we complained that
_X_ browser wouldn't support _Y_ or that we needed to build custom gird systems
to meet our project needs. We've come a long way, most of us use CSS
[Grid](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Grid_Layout) and
[Flex](https://developer.mozilla.org/en-US/docs/Web/CSS/flex) pretty freely and
long-gone are the days of installing a Bootstrap for its Grid System.

Now that developers have mostly quit their moaning about CSS the focus has moved
to designer-developer handoff and as part of that, the management of design
systems. One such application is outlined in [Atomic
Design](http://atomicdesign.bradfrost.com/) by Brad Frost. By using design
systems and creating a single source of truth for them, developers and
designers can be at peace knowing that the designer's design isn't being murdered
by the developer, and that the designer isn't designing anything beyond whats
sensible.

Design Systems make a whole load of sense for Application System UI, or simple
compositions of rectangles, images, text. However, when applying this to more
complex website designs or interesting consumer-facing apps, we end up with
headaches. The design will break when the screen gets smaller (unless your
designer has designed for every pixel screen size--unlikely), your text will
need to scale between mobile and desktop and work everywhere between.

### In Comes, Fluid Typeography

Let's say you have a mobile design and a web design, on the web your Title has a
font size of `22px` and on mobile `18px`, we might do something like this:


```css
.title {
  font-size: 18px;
}

@media screen and (min-width: 400px) {
  .title {
    font-size: 22px;
  }
}
```

With Fluid Typography we'd scale the `font-size` relative to the width of the
screen and between the 2 values, treating the mobile value as the smallest possible
`font-size` and the desktop as the largest. So, in effect we want to `calc()`
the following chart, where the X Axis is the known screen width and the Y Axis
is the output.

![](/linear-type.png)

Note that in our case we've assumed that the smallest scaling screen size is
400px wide and the largest is 1200px. The equation for this is as follows:

```txt
(1 / (largeScreen - smallScreen)) * (maxType - minType) * (screenWidth - smallScreen) + minType
```


Which in our case looks like:
```txt
(1 / (1200 - 400)) * (22 - 18) * (screenWidth - 400) + 18
```

This equation will produce a linear scaling font-size, we now need to limit
the equation at the top (1200px) and bottom (400px) values, we can do this using
a couple of good ol' media queries:

```css
.title {
  font-size: 18px;
}

@media screen and (min-width: 400px) {
  .title {
    font-size: calc((1 / (1200 - 400)) * (22 - 18) * (100vw - 400px) + 18px);
  }
}

@media screen and (min-width: 1200px) {
  .title {
    font-size: 22px;
  }
}
```

Now that your font is dynamic, you'll quickly realise that the rest of your
design breaks or behaves inconsistently. Rectangles, images and the alike are
likely to also need to be scaled along with your text - with exceptions.

### Fluid Containers

It may sound obvious, but it's often the case that text containers are designed
as if the text perfectly wraps at the same character as the screen changes width, a
difficult problem when the text also scales. To achieve this we can use [CSS
`ems`](https://developer.mozilla.org/en-US/docs/Learn/CSS/Introduction_to_CSS/Values_and_units#Numeric_values)
to scope the font-size to a wrapping element.

For example, lets say we had text that scaled from 18px-22px within the
viewport sizes 400px-1200px (same as above), and we wanted the container element
to scale according to the font-size.

```html
<div class="title">
  <div class="box">
    My title in a box.
  </div>
</div>
```

```css
.title {
  font-size: 18px;
}

@media screen and (min-width: 400px) {
  .title {
    font-size: calc((1 / (1200 - 400)) * (22 - 18) * (100vw - 400px) + 18px);
  }
}

@media screen and (min-width: 1200px) {
  .title {
    font-size: 22px;
  }
}

.box {
  width: 10em;
  height: 10em;
  background-color: tomato;
}
```

### Summary

Although this solution may seem a little unconventional and complex, it will
hopefully, help in trying to build a system behind complex and nuanced designs
where necessary.

Implementing Fluid Design Using the CSS calc() Function

How to survive a Penetration Test as a GraphQL developer

A Practical Guide to Choosing Your Next React Framework

Some of our favorite clients are startups — working directly with founders who
want to build beautiful, user-centric apps on tight timelines and often tighter
budgets. Development in this environment can mean that time on features is
prioritized over protection which is great for an MVP launch but doesn’t hold up
as products begin to scale and attract attention. We experienced this first hand
at a previous startup that we worked at, and have carried that lesson with us
into our current client work. We‘ve been evolving our process to ensure we
secure our backends over the past couple of years, whilst not impacting our
quality or speed for clients. Recently we were lucky enough to have that put to
the test by one of our clients. The company was acquired by a larger
organization who naturally wanted to perform an enterprise level Penetration
Test on the app before dishing out their cash.

![](/evil-pen.jpeg)

In this post, I outline a few GraphQL specific security practices that we can
now say have been battle-tested. It is by no means an exhaustive list but
includes some helpful recipes for securing your API. For a more in-depth
reference, you should refer to
[OWASP](https://www.owasp.org/index.php/Main_Page)

Although most of these points are relevant to any tech stack (or should be
translatable), the tech-stack in question and the one we most commonly use is:

* NodeJS

* GraphQL

* Postgres

* React/React Native

This post assumes knowledge of directives in GraphQL. However, if you’ve not
seen them before it should hopefully still be readable!

*Apollo is a good place to [learn about them](https://www.apollographql.com/docs/graphql-tools/schema-directives.html).*

## Access Control

Access Control, also known as Authorization, is how your application permits
access to resources in your app. Security 101, right, but in anything bigger
than a tiny hobby app, it's easy to leave holes in the bucket.

GraphQL makes it simple and elegant to manage access to resources. Suppose the
following:

```graphql
type Query {
  getMyData: Data @authenticate somePublicData: String
}

type Mutation {
  updateAnItem(id: ID!, name: String!): Item @authenticate
}
```

We authenticate each private field with a custom directive and leave the public
fields directive-free. The danger is that we stop here, call the system ‘secure’
and release. The likelihood is that, without being security conscious, you’ve
gone an implemented the updateAnItem resolver like this:

```js
const updateAnItem = (root, args) => {
  return Item.update({ name: args.name }).where({ id: args.id });
};
```

Although you *have* authenticated generic access to updateAnItem, you haven’t
checked that this user should be allowed to update this item. Granular
authentication must happen at the application logic level, which makes it very
hard to keep track of as your application and team grows. The corrected resolver
could look like:

```js
const updateAnItem = (root, args, ctx) => {
  return Item.update({ name: args.name }).where({ id: args.id, userId: ctx.userId });
};
```

Keep an eye out, educate your team to check for them during code-reviews and
write automated tests to help guide best practice and prevent regressions.

## Anti-Automation

Most applications are under threat from brute-force attacks on passwords,
verification codes or any string that provides some-sort of authorized access to
your system. All it takes is a hacker to execute a script that iterates through
likely combinations until it strikes gold.

The first step to at least partially cover you would be to add error tracking
and alerts to your system. We use [Sentry](https://sentry.io), but there are no
doubt others that do a similar job. Log every error that is thrown and set an
alert for when it occurs at a frequent rate.

However, if you don’t want to be woken to a trillion alerts from Sentry, then
I’d also recommend adding rate-limiting to your vulnerable fields. We’ve built a
small directive library for controlling this, it’s as easy as:

```js
import { createRateLimitDirective } from 'graphql-rate-limit';

const server = new ApolloServer({
  typeDefs: gql`
    type Mutation {
      # Limit to 10 per minute
      login(email: String!, password: String!): String! @rateLimit(max: 10, window: 60000)
    }
  `,
  resolvers: {
    Mutation: {
      login: () => { /* ... */ }
    }
  },
  schemaDirectives: {
    rateLimit: createRateLimitDirective({
      identifyContext: ctx => ctx.req.ip
    })
  }
});
```

More info here:
[https://github.com/teamplanes/graphql-rate-limit](https://github.com/teamplanes/graphql-rate-limit)

## Server-Side Validation Checks

It can be easy to forget that your UI is **not **the only interface to your
system with the ability to make updates and interact with your business logic,
🤦🏻‍♂️. A side-effect of this could be that validation checks are baked into
the client, and not the server. An example being email verification, perhaps the
user **should** be able to log in whilst their email is not verified yet, but they
shouldn’t be able to update their profile or create some data.

Validation checks should be built into your Access-Control, not your UI. So
perhaps you can abstract it out with a withEmailVerified directive or you may
need to implement in your data layer.

```graphql
type Mutation {
  login(email String!, password: String!): String
  updateProfile: Profile @withEmailVerified
}
```

## Verbose Error Messaging

A silly mistake, but an easy one to clear up. In development, it’s handy to
deliver the full error message and stack trace to the client, but doing this in
production could give a hacker enough understanding of the inner workings of
your system to exploit it.

Take the following, you have a simple query that accepts an ID (a string) and
the resolver of getItemById passes the ID into a Postgres query.

```graphql
# Shema
type Query {
  getItemById(id: ID!): Item
}

# Query made by client
query myQuery {
  getItemById(id: "*") {
    id
  }
}
```

You’d end up with an error that could look a little like:

select * from \”items\” where \”id\” = $1 — invalid input syntax for integer: \”
*\”

Although this particular message doesn’t give us much other than telling us that
there is a table ‘items’ and it has a column named ‘id’. You can easily see how
if we had a few other tables referenced, you could build up a picture of the
database structure. An attacker could follow a similar process to piece together
business logic structure or class implementations.

Most GraphQL server libraries allow you to mask or reformat error messages, with
Apollo Server you’d end up with:

```js
new ApolloServer({
  typeDefs,
  resolvers,
  formatError: error => new Error('Internal server error')
});
```

### Summary

Although this is certainly in-exhaustive, hopefully, these points help you in
starting on a journey to securing your GraphQL API. Securing your API is never *‘done’*,
I’d strongly recommend taking a browse through OWASP, a good place to
start is with the [OWASP Node Goat project’s Top 10](http://nodegoat.herokuapp.com/tutorial).

For further reading on GraphQL specific security concepts, [Max
Stoiber](undefined)’s post on [Securing Your GraphQL API from Malicious
Queries](https://blog.apollographql.com/securing-your-graphql-api-from-malicious-queries-16130a324a6b).

The idea of a digital agency Product Manager might seem strange at first glance.
Especially in a tech startup, where the founder has a clear vision of the
product, and a deep understanding of the target user. Not to mention the
authority to create change. But the humble Product Manager is not on the rate
card without good reason. Well, five good reasons to be precise.

## 1. We're here to save you time and money

Ambitious by nature, founders often envisage complex feature sets when
developing or iterating a product. No big surprise given the countless hours
they’ve spent dreaming up their perfect app. As Product Managers, our job is to
challenge you to do less; or, rather, do only what is required to meet your
goals.

By assessing your objectives we’re able to advise on what to build and
how. After all, there is no value in building 'cool feature x' unless we can
prove it’s going to shift the needle. There’s also no value building ‘cool
feature x’ from scratch if a third party option exists that’s going to save you
time and money.

Being a 'yes' person is always the path of least resistance, so,
challenging founders can be an uncomfortable process for Product Managers. But
the success of your business is our top priority, so we will always challenge
your thinking if there’s a chance it will elevate the results.



## 2. We're here to be the voice of your people

Though many founders have spent months if not years investigating what makes
their target audience tick, Product Managers are there to interrogate the
findings, and also discover new ones.

In the long, often drawn-out process of ideation, it’s not uncommon for founders
to develop cognitive bias around their users. For example, a 'confirmation bias'
is where you inadvertently seek out information to support what you already
believe to be true. Do the majority of the users really want to see 'cool
feature x', or just the users you want to listen to? We’re here to help you find
out.

As a business grows, founders also tend to have less time for active user
research, including the response to new features, or any changes to the product
or product context. Product Managers work to fill in those blanks, so the
founder can stay focused on the bigger picture.



## 3. We're here to share our bag of tricks

Whilst most founders possess a clear vision of their product and the desired
output, not all come from a product background. An agency Product Manager brings
the processes and tools to help execute that vision. From payment gateways and
CRMs to analytics and user research, we bring both the experience and expertise
to make problems a thing of the past, and turn your ideas into actualities.


## 4. We're here to do the dirty work

For those familiar with SCRUM parlance, the Product Owner is responsible for
managing the development backlog, ensuring work is correctly scoped, unblocking
developers, overseeing testing and releases, and maximising workflow
improvements. For most Planes projects,  Product Managers will also take on this
less than glamorous but critical role to make sure we are delivering maximum
value to our clients.



## 5. We're here to get the job done

The terms Project Management and Product Management are often confused. While
Product Management supports the founder in defining the what and why of the
product, Project Management deals with the how and when. Product Managers at
Planes wear both hats (but only one at time because wearing two hats looks
ridiculous), so founders can sleep soundly knowing specifications are agreed,
timelines are maintained, risks are managed, resource is planned, and
stakeholders are covered.




As Product Managers, we not only have access to an incredible range of tools and
processes, we also have the nous to use them. And even though the tasks and
requirements may vary from project to project, the Product Manager’s purpose
remains the same: to collaborate closely with our clients to build the best
product possible and, in turn, the best possible business.

Product Managers: The secret weapon of successful digital products

We've started (and finished 😊) a lot of projects here at Planes, and being a
team that loves to try new tools, we've gained a lot of experience in what works
and what doesn't for React projects. It can often feel daunting making the
choice since the most popular frameworks dictate very different approaches to
setting up your projects. Hopefully, this post clears up a few of the key
decision points when setting up your project.

In this post, I'll run through the reasons for using a framework and it's
caveats, specifically, the following:

- [Create React App](https://facebook.github.io/create-react-app/)
- [Gatsby](https://www.gatsbyjs.org/)
- [Next.js](https://nextjs.org/)

Not an exhaustive list, however, these are currently a few of the most popular
ways of starting and building a React app, each with their own distinctive
use-cases.

### Create React App

**High-level**: A tool to help you set-up a single-page React application

**Description**: Create React App is ofter the first tool you'll use when
getting started with React, mostly due to its simplicity (and it's ties with
React itself). However that's not to say it can't be used for a production web
app, CRA comes with a number of advanced features out-the-box including
TypeScript, advanced caching using service workers, Progressive Web App support
and code-splitting. If your project grows out of CRA and, for example, you need
to add some custom functionality to the build process you can always override
the defaults using
(react-app-rewired)[https://github.com/timarney/react-app-rewired] or even eject
from it completely.

**Caveats**
- SEO, although search engines do mostly crawl JS these days it's probably not
the best fit if this is important to your project.

**Example use-cases**
- An internal admin dashboard
  - **Why?** Because you want to be able to work quickly, you aren't fussed
  about SEO and, being a single-page-application, it will feel snappy.
- A responsive, offline-first web app
  - **Why?** Because CRA comes out of the box with a service-worker for offline
  support and code-splitting for better performance on mobile.


### Gatsby

**High-level**: A React static-site generator

**Description**: With a clear use-case, Gatsby is the go-to for React blog
developers, in fact, this site was built with Gatsby. Building your Gatsby
project will result in each of your React pages outputting a single HTML page.
As you can imagine this is a very preferment way of serving up a React app as
all the work done by React is at build time rather than in the browser or on a
server. You can also leverage off a large library of Gatsby Plugins, examples
include tools to optimise images at build time and tools for generating
sitemaps.

**Caveats**
- If you have lots of Dynamic Content or require users to authenticate then
Gatsby might not be for you. Although it is all possible, you'll likely run into
more headaches than its worth.

**Example use-cases**
- A Contentful Blog
  - **Why?** Gatsby can be generated based on a data source such as Contentful,
  meaning your blog writers can write from the comfort of a Headless CMS and you
  can build the site in React.
- An SEO optimised marketing website
  - **Why?** Because gatsby sites can be very quick to load, and there are lots
  of handy tools for optimizing images and outputting SEO boilerplate such as
  sitemaps and metadata.


### Next.js

**High-level**: A framework for building Server Side Rendered (or SSR) React apps

**Description**: Next.js solves what was previously a very difficult problem -
server-side rendered React. SSR involves building a static version of a
page/component on a server, delivering it to the DOM where it then behaves like
normal client based React. There are SEO benefits to being pre-rendered (a
search engine could crawl the page without JS enabled), and performance benefits
as your code can be split by page and cached in its rendered state on the
server.

**Caveats** - As your app grows in complexity you will likely come across
ergonomic issues, changes to how you might have previously implemented
authentication for example, and other issues that you might not come across with
a simple client rendered React app. It's easy to look at the Next.js website and
think that it is as easy as writing React.

**Example use-cases**
- A Medium style site where logged-in users publish public crawlable content
  - **Why?** Next.js is server-rendered, so all content will be SEO ready whilst
  also providing you the framework for implementing logic such as authenticating
  other parts of your app.
- A Blog or Marketing site
  - **Why?** Although Gatsby is in some ways more suited to this use case,
  Next.js does have all the characteristics of an excellent framework for this
  use case. In fact, working with Next.js when you don't need it's more advanced
  features reduce it down to a very simple and enjoyable development experience.

## Summary

Although you are never fully locked in, it's worth looking at your projects
likely long term requirements and choosing based on those. At Planes we find
ourselves using Next.js for the majority of Web Applications and Gatsby for
static sites, but love it when we get the opportunity to use CRA, just for its
simplicity.

Our Insights

We build cool stuff with cool people.

How to survive a Penetration Test as a GraphQL developer

A Practical Guide to Choosing Your Next React Framework

Implementing Fluid Design Using the CSS calc() Function

Building End-To-End Form Validation with Yup, graphql-shield and GraphQL