Discussion on: GraphQL APIs or RESTful APIs

[JoelBonetR 🥇]

Interesting surface insight. I suggest you to do some tests on a micro-service architecture application so you can get the experience with that :)

Both tech can be used on the same project, they simply come to solve different needs.

A thing that is usually forgot when talking about GraphQL is that you can delegate the resolvers to another micro-service. I'll try to explain it briefly.

Imagine you've a Node.js Apollo GraphQL API, you'll get your entry point that handles routes, your schemas and your resolvers. This way you relieve some server load and avoid having a big service using GraphQL instead having microservices.

Example:

const resolvers = {
  Query: {
    stocktwitstrending: async (_source, _args, { dataSources }) => {
      let trendingList = await dataSources.stockTwitsAPI.getTrending()  
      return trendingList
    }
  }
}

This way the GraphQL point is a good kind-of middleware or gateway where you simply handle your front-end (or external client) requests.

In this example,

dataSources.stockTwitsAPI.getTrending() 

can be a caching-enabled REST API so it minimises the impact about non-cached server responses.

Also Node (javascript currently, Node is just a runtime environment) is good for handling high i/o operations but as long as JS runs in a single thread we can struggle doing operations that implicitly adds high CPU load, so this

dataSources.stockTwitsAPI.getTrending()

can be a Python (or Kotlin, or Java, or C# or Rust or Go...) API that handles this high CPU demanding tasks.

*You can achieve multi-thread computation on JS node using clustering or by server config but this is a different subject

And last but not least you can choose different data transport protocols such gRPC if you need performance so you can avoid parsing JSONs. This, also is a different subject but related as most things are in computation science.

Well this is just an approach that came to my mind, there are multiple ways of implement solutions and we always should made a deep analysis before implementing. Hope it helps :)

---

Edit:

There is no certain way to do things, and we can go on and on about which way is the proper way to do things or which has better advantages over the other. I think as far as you get your problem solved in an efficient and effective manner then it's quite the right way to do it.

It depends on you being an engineer doing engineering work or you being whatever and doing technical work only.
If you are engineering something you should analyse all the required points for your software solution and end up with a tech stack, architecture, paradigm, pattern/s... that fits better to your software needs. We really don't need -most of time- to engineer brand new things but understanding the existing ones and take advantage of that. So for a given problem, there will be always one solution that is better than the others. It can be in terms of CPU load, maybe memory, time... using the metric/s that impacts most your functionality or service is a good way to find out which is the best approach and if you can set some test cases on a test suite you'll end up with empiric results as well.
If you are doing technical work you usually will just focus on implementing things that others decided but if you imply in this process and read and learn about related things about software engineering, you can grow up in this career path that is project development.

[Kinanee Samson]

Hmm, thanks for opening the door to more interesting thing one can do with graphQL. I'll definitely look at the micro-service architecture