DEV Community: Yusuf Bozacı

REST vs GraphQL: How to Choose the Right API for Your Project

Yusuf Bozacı — Tue, 13 Oct 2026 20:51:03 +0000

REST vs GraphQL: How to Choose the Right API for Your Project

Choosing between REST and GraphQL isn't really about which technology is better. It's about which problems your application needs to solve.

Both approaches can power a modern application. Both can return JSON over HTTP. Both can work with almost any database.

But they make different trade-offs, especially when it comes to data fetching, caching, and complexity.

Let's break down the differences using a practical example.

The problem: Fetching data for a user profile

Imagine you're building a dashboard that displays:

The user's name and email
Their latest five posts
The number of comments on each post

With a typical REST API, you might make requests to multiple endpoints:

GET /api/users/42
GET /api/users/42/posts?limit=5

Depending on your API design, you may need additional requests for comment counts.

A well-designed REST endpoint can also return everything in one response. REST doesn't require multiple requests, but resource-oriented APIs often encourage separating data into endpoints.

Now let's look at GraphQL.

query {
  user(id: "42") {
    name
    email
    posts(limit: 5) {
      title
      commentCount
    }
  }
}

One query describes exactly what the interface needs.

That's the biggest difference: GraphQL gives clients more control over the response shape.

1. Data fetching

With REST, servers generally define the structure of each endpoint's response.

For example:

{
  "id": 42,
  "name": "Alex",
  "email": "alex@example.com",
  "createdAt": "2024-01-01",
  "preferences": {}
}

But what if your interface only needs the name?

You might receive unnecessary information, commonly called over-fetching.

GraphQL allows the client to request specific fields:

query {
  user(id: "42") {
    name
  }
}

However, this flexibility isn't always necessary.

If your application has a few predictable screens, carefully designed REST endpoints may be simpler to maintain.

2. Caching

REST has a practical advantage: HTTP caching.

A request such as:

GET /api/products/123

can use standard HTTP caching mechanisms, including cache headers and CDNs.

GraphQL caching often requires more thought because many implementations use a single endpoint with POST requests.

Libraries such as Apollo Client provide normalized caching, but your team still needs to understand how cache identities and updates work.

GraphQL can also use GET requests and persisted queries, so caching isn't impossible. It simply requires different design decisions.

3. API contracts

GraphQL uses a strongly typed schema.

For example:

type User {
  id: ID!
  name: String!
  email: String!
}

This gives frontend developers a discoverable contract.

REST can achieve similar benefits using OpenAPI, JSON Schema, and generated TypeScript clients.

The difference isn't whether type safety is possible. It's how that contract is defined and maintained.

4. Performance

A common misconception is that GraphQL is automatically faster than REST.

It isn't.

GraphQL can reduce network round trips and unnecessary fields, particularly on mobile networks.

But complex queries can also introduce expensive resolver operations, deeply nested relationships, and N+1 database queries.

For example, requesting 100 users and each user's posts can accidentally generate hundreds of database queries if resolvers aren't designed carefully.

REST has performance challenges too, but its more predictable endpoints can be easier to monitor and cache.

Always measure actual application performance instead of choosing based on assumptions.

5. When should you choose REST?

REST is often a good choice when:

Your application has predictable data requirements.
You are building a straightforward CRUD API.
HTTP caching is important.
You want a simple public API.
Your team prefers minimal infrastructure complexity.

6. When should you choose GraphQL?

GraphQL becomes attractive when:

Multiple clients need different data shapes.
Your frontend combines many related resources.
You have complex dashboards or mobile screens.
You want a strongly typed, discoverable API schema.
Your team can manage resolver performance and query complexity.

The important part: You don't have to choose only one

It's perfectly reasonable to use both.

For example, your internal services might expose REST endpoints, while a GraphQL layer combines their data for your frontend applications.

The best architecture is the one that solves your actual problems with the least unnecessary complexity.

If you want a quick side-by-side reference, Software Dictionary's REST vs GraphQL comparison summarizes the differences, common misconceptions, and examples.

Final thoughts

Don't choose GraphQL just because your application uses React.

Don't choose REST only because it's familiar.

Think about your data requirements, team experience, caching needs, and maintenance costs.

Start with the simplest approach that meets your requirements. Introduce additional complexity when you have a clear reason.

The right API is the one your team can understand, maintain, and evolve.

Semantic Commit: Guide to Regular Commit Messages

Yusuf Bozacı — Mon, 25 Nov 2024 21:05:00 +0000

Hello Everyone! 👋

Your commit messages are more than just recording changes to your codebase. Effective and regular commit messages increase your team's collaboration, provide a better understanding of the code, and make debugging easier. In this article, I will share a guide to writing an effective commit message based on semantic commit principles. You will also see how you can streamline your processes with semanticcommit.com.

What is Semantic Commit?

Semantic Commit is a method used in software development. Its main purpose is to ensure that commit messages (i.e., messages associated with each change made to the code) are more meaningful and structured. This way, developers can more easily understand when, why, and what changes were made to the code.

Why Are Commit Messages Important?

Easily Understandable Changes
Each commit message clearly describes the changes made. This way, while working on a project, you can quickly understand what changed in the code and why. For example, instead of saying 'just some edits made,' a clear explanation like 'new login page added' is provided.

Faster Issue Resolution
When there is a bug in a project, it becomes much easier to find the changes that might have caused the issue by reviewing past commit messages. Meaningful and structured commit messages help you quickly locate and resolve errors.

Version Tracking
Semantic Commit helps you see more clearly which changes were made in which version of the project. For example, when a new feature is added, the version number can be updated. This makes it easier to keep the project up to date.

Team Collaboration
When working with multiple people, having everyone write commit messages in the same way keeps the project organized. This way, one team member can more easily understand what another has done, increasing collaboration.

Easier Project Management
As the project grows, there may be hundreds or even thousands of commits. Meaningful commit messages make it easier to manage the large project and track changes over time.

Commit Message Structure

Semantic Commit messages are written according to a specific rule. These rules make the structure of each commit message meaningful and consistent.

1. Type

This indicates the type of change made. It is added at the beginning of the commit message. Common commit types include:

feat: Used when a new feature is added.
fix: Indicates that a bug has been fixed.
docs: Used if only documentation-related changes are made.
style: Changes that do not affect the code's functionality, only related to formatting (e.g., correcting spaces or punctuation).
chore: Non-functional changes to the code or dependencies. For example, package updates or changes in build configurations.
refactor: Used to restructure the code without changing its functionality.
test: Used to add or update tests.
perf: Used for changes made solely to improve performance without altering functionality.
ci: Used for changes related to continuous integration configuration.
build: Used for changes related to the build system, such as build settings or dependency management.
revert: Reverts the effects of a previous commit.

2. Scope (Optional)

Specifies which module, file, or component the change was made on. It is written in parentheses along with the type.

Examples:

feat(auth), fix(ui), docs(readme), style(header), chore(deps), refactor(api), test(login), perf(image-loader), ci(travis), build(webpack), revert(api)

3. Subject

Briefly and concisely describes what the commit does. It should be written in a maximum of 50 characters.

Examples:

feat(auth): add login functionality
fix(ui): resolve button alignment issue
docs(readme): update installation instructions
style(header): fix indentation
chore(deps): update axios to v0.21.1
refactor(api): optimize fetch method
test(login): add unit tests for login function
perf(image-loader): optimize image loading for faster page speed
ci(travis): add deployment step to pipeline
build(webpack): update webpack configuration for faster builds
revert(api): revert API changes that caused issues with data fetching

Conclusion

Effective commit messages directly affect not only your developer experience but also the overall success of your project. With Semantic Commit, you can make this process more organized, understandable, and efficient.

Be sure to try semanticcommit.com to write better commit messages!

Remember, regular commits are the foundation of regular projects. 🚀