DEV Community

Cover image for 5 mistakes to avoid when getting started with GraphQL
Tomek Poniatowicz for GraphQL Editor

Posted on • Edited on

5 mistakes to avoid when getting started with GraphQL

Being short-sighted

It’s a mistake that can lead to serious complications later on. Thinking about your schema try being as predictive as possible in terms what can be required later on when your project grows. Even if you think that initial odds of this happening seems very low, take a while to plan through possible future elements like additional fields or output/input object types. If there is even a tiny change that you will need them in the future, having them thought through will prevent your project from breaking changes later on.

Remember: A schema is a most important part of any GraphQL project so make sure to treat it with all due respect!

Plan your schema!

Inconsistency in naming

It's really important to keep naming conventions consistent. There are some common practices you shouldn't ignore, like:

  • using camelCase for fields
  • using PascalCase for the names of types
  • using all capital letters for ENUM values

Flattening objects in queries

There are a lot of mistakes you can make when "speaking" GraphQL. Not only mistakes that might prevent your project form working properly, but also that they won't use GraphQL possibilities to the fullest. A good example is a type we have created above.

Avoid queries like this

The leageId is a problem here as this will be seen as an inconsistency. When querying for a team’s league you need to perform two database calls:

  • to get the team with the leagueId
  • to pass the leagueId to another query

This is very negligent as GraphQL it's all about reducing the number of database calls. The GraphQL preferable way is nesting the output types which makes it easier to call your database with a single request and batch your data:
Try structurize your GraphQL queries this way

Not using graphical interfaces

GraphQL is a very modern "language" so there are a lot of amazing tools, plugins or editors that can speed up the schema design process so why not using them? If you are starting your journey with GraphQL it is a great idea to design your first schema with a graphical interface. This will reduce the number of mistakes, speed up your work and learning curve of GraphQL by a lot!

GraphQL Editor

Not using GraphQL

If you are still focusing on REST you are making a canonical mistake. As none of them is perfect and both have pros & cons, it's really wise to know them both and then make a rational decision which would suit your project better.

Top comments (9)

Collapse
 
petarov profile image
Petar G. Petrov • Edited

Nice write up! I don't have any GraphQL experience, but I'm trying to get into it. I've got one question about the paragraph:

This is very negligent as GraphQL it's all about reducing the number of database calls. The GraphQL preferable way is nesting the output types which makes it easier to call your database with a single request and batch your data:

As far as I understand it, DataLoader's batching works on the event-loop level. When it comes to SQL databases it'd still be the responsibility of the backend that fetches the data from the database to actually provide the right (optimized) query, right? I mean, a batch could still result in several SQL SELECTs, if a query with a, e.g., WHERE clause, isn't available.

Collapse
 
aexol profile image
Artur Czemiel

In my opinion dataLoader is more abstract tool which can be used within specific patterns. It doesn't replace SQL queries of course, but you might be confused by a lot of SQL examples inside README. Using it with resolvers and GraphLQ is up to you. You can reduce the number of calls if you want to query just exact fields.

Collapse
 
hassanfarid profile image
Hassan Farid

+1 - I have same question. API returns the results all at once, but database get queried in each loop, instead of joins that are possible in most SQL data sources.

Collapse
 
revskill10 profile image
Truong Hoang Dung • Edited

For graphql, what i need is automatic fragments, typings, queries, mutations generation. Those are selling points of graphql, so if you have to manually type graphql query, you're doing it non-optimally.

Collapse
 
gerardolima profile image
Gerardo Lima

Yes, yes drop REST at all... What a fraud. Would you implement a single SP to fetch all data from a database? Why the hell one would think doing that with http requests world work nicely?

Collapse
 
tomekponiat profile image
Tomek Poniatowicz

Calm down :) What I meant is that you should stop being blindfolded and open your eyes on GraphQL.

Collapse
 
gerardolima profile image
Gerardo Lima

You are right, @Tomek :) I've just read too many hype articles praising GraphQL as a silver bullet and I took it all on yours ... my bad.

Collapse
 
ianrathbone profile image
Ian Rathbone

Thanks very useful!

Collapse
 
lukaszzarski profile image
Łukasz Żarski

Thanks, that was useful!