The GraphQL Inflection Point: Moving Beyond REST in 2018

It’s late 2018, and the limitations of traditional REST APIs are becoming increasingly evident as we build more complex, data-driven mobile and web applications. We’ve all faced the same problem: an endpoint that returns a 2MB JSON object when the UI only needs the username and avatar_url. Or worse, having to make four separate API calls just to render a single dashboard view.

At our agency, we are moving toward GraphQL. Originally developed by Facebook and open-sourced in 2015, GraphQL has reached a level of maturity in 2018-thanks to the Apollo ecosystem-that makes it ready for production-grade enterprise applications.

1. The Power of the Schema

The biggest shift in GraphQL isn't just the query language; it's the Strongly Typed Schema. In 2017, we relied on Swagger or manual documentation to tell the frontend team what the backend returned. These docs were almost always out of date.

With GraphQL, the schema is the documentation. By defining our types in SDL (Schema Definition Language), the frontend team can use tools like GraphiQL to explore the API and even generate TypeScript interfaces automatically.

# Our 2018 Schema Definition
type User {
  id: ID!
  username: String!
  posts(limit: Int): [Post]
}

type Post {
  id: ID!
  title: String!
  content: String
  author: User!
}

type Query {
  me: User
  recentPosts: [Post]
}

2. No More Over-fetching on Mobile

Mobile users in 2018 are still fighting with limited data plans and latent 4G/3G connections. REST is inherently wasteful because the server defines the response structure.

In GraphQL, the client defines the response. If the mobile app only needs the title of a post, that is all the server sends.

# Client-side query: Only get what is necessary for the UI
query GetRecentPosts {
  recentPosts {
    id
    title
    author {
      username
    }
  }
}

This drastically reduces the payload size and the time spent parsing JSON on low-end devices.

3. Resolvers: The Backend Abstraction Layer

One concern we hear from backend engineers is: "Do we have to rewrite our entire database logic?" The answer is no.

GraphQL acts as a layer that sits on top of your existing services. A "Resolver" function can fetch data from a legacy MySQL database, a new MongoDB collection, or even a third-party REST API. This allows us to modernize the frontend experience without a high-risk backend rewrite.

// A typical 2018 Apollo Resolver
const resolvers = {
  Query: {
    me: async (parent, args, context) => {
      // This could be a DB call or an internal fetch
      return await context.db.Users.findById(context.userId);
    },
  },
  User: {
    posts: async (user) => {
      return await context.db.Posts.find({ authorId: user.id });
    }
  }
};

2018: The Year of the "Graph"

As we close out 2018, the "Graph" mental model is replacing the "Resource" mental model. By treating our data as a connected graph rather than a list of disconnected URL endpoints, we are building faster, more flexible applications.

If your team is struggling with API documentation or slow mobile performance, it’s time to look at GraphQL. We are currently integrating it into all our new mid-to-large scale projects, and the developer experience (DX) improvement alone is worth the switch.

---

Aunimeda develops websites and web applications for businesses - corporate sites, e-commerce, portals, and custom platforms.

Contact us to discuss your web project. See also: Web Development, E-commerce Development