The Hidden Cost Of GraphQL And Node.js
GraphQL has gained popularity in recent years as a querying language for APIs. It is praised for its flexibility, efficiency, and simplicity. Node.js, on the other hand, has become the go-to platform for building scalable and performance-driven web applications. While both technologies have their merits, it is essential to understand the hidden costs associated with using GraphQL and Node.js.
One of the significant concerns with GraphQL is its steep learning curve. Developers need to familiarize themselves with a new syntax and way of thinking about data fetching. This learning curve can result in longer development times and increased costs. It may require additional training or hiring developers who already have experience with GraphQL, which can be expensive.
Another hidden cost of GraphQL is the complexity it introduces to the server-side implementation. While GraphQL simplifies the client-side code, the server-side code can become more complex as it needs to handle incoming queries, resolve data from various sources, and apply business logic. This complexity can lead to longer development times and potentially higher maintenance costs.
Node.js, being a runtime environment for server-side JavaScript, has gained popularity for its ability to handle large amounts of concurrent connections and its scalability. However, with this scalability comes the cost of increased server resources. As Node.js is single-threaded, it can suffer from bottlenecks when handling CPU-intensive tasks. In scenarios where computation-heavy operations are required, additional server resources may be needed to maintain performance, leading to higher infrastructure costs.
Moreover, Node.js is not suitable for all types of applications. It is primarily designed for IO-bound operations, making it an excellent choice for applications that rely heavily on network requests, such as real-time applications or RESTful APIs. However, for CPU-bound applications where heavy calculations are required, Node.js may not be the most efficient choice. In these cases, using other languages or runtime environments might be more cost-effective.
Additionally, the modularity and flexibility of Node.js can lead to a large number of package dependencies. While packages can speed up development and provide necessary functionality, they can introduce risks. Packages may contain vulnerabilities or lack active maintenance, requiring constant monitoring and updates. This can lead to increased maintenance costs and the need for a robust dependency management strategy.
In conclusion, while GraphQL and Node.js offer many advantages for building modern web applications, it is crucial to consider the hidden costs associated with them. The learning curve, increased server resource requirements, server-side complexity, and dependency management challenges can all contribute to higher development and maintenance costs. It is essential to carefully evaluate your project’s requirements and determine if the benefits of adopting GraphQL and Node.js outweigh the associated costs.
"Graphquill" and "Squeal" 😅 I agree though. The only platform where GraphQL should be used on is Rust with async_graphql and actix or axum ✌️
The Structured Languages for Queries (SLQ) should of course be pronounced as "slick" 😉
Meanwhile me happily using threads, async and such noice stiff like this in c# without any drama
Maybe I'm misunderstanding something basic here, but isn't all async code basically the same under the hood? Callbacks will also get pushed to the tail of the event loop and actually get executed whenever is their turn, won't they?
I was conducting some interviews in my previous job. I had a few questions to go over to see how well they understood js. Most of them couldn't tell me how you can perform async tasks without promises. Callbacks are a forgotten technology for most devs in their 20s.
I missed the reference/joke about asking javascript devs to not write promises and them being mind blown 😬 can anyone explain please
This is wrong. If you have no await (.then() abstraction) inside of an async function, then(no pun intended) the only time it gets pushed into the microtask queue is when it returns. This is because async functions return vals are wrapped in promises.
>problem: resolvers being inefficient
>solution: n squared in-memory join over items vs itemDetails via .find
Really good explanation we need to keep this in mind. I had one thought how are Observables and Subjects vs Promise
This whole vid showed an incredible lack of understanding of programming in general and js and node in particular
This guy is obnoxious. Smart, but god awful to listen too. Annoying af.
I’m out.
"We need a semantic query language"; enter SPARQL https://en.wikipedia.org/wiki/SPARQL
(but be prepared to learn a whole new data / devops stack)
The individual promise thing is definitely not sensible in the graphql context.
It would be a bit different if it was like a component system where you want state for something as low as possible, so you might have many components making similar calls for different data that can be batched into a request. Where doing the extra request in a single promise from the top could be impractical or increase dataloading.
These issues can be addressed based on the database, for example GraphQL has a graph structure, Neo4j is a graph DB, the Neo4j-GraphQL library transforms GrapQL queries into Cypher (SQL for graph DBs) queries, since Neo4j takes care of the whole query instead of GraphQL resolvers chatting, it removes the "chatty protocol" part, or the "n+1" issue common in GraphQL, though not sure how this could be fixed in non graph DBs…
What the hell?
Callback hell
You are correct that writing SQL is better than ORMs. Ted Neward explained the problem pretty well in his article, "The Vietnam of Computer Science".
The resolver doen't need to run several call per field. It can one query instead. Building own GraphQL endpoint is a waste of time. It's simpler and faster to use Hasura GraphQL server.
idk man 2 SQL queries for that? hmmm can we trust the rest of this?
As a fullstack developer who writes backend code in Java, it baffles me that something that is supposed to run async is processed synchronously and single threaded in node…