The Hidden Cost Of GraphQL And NodeJS

Senior JavaScript developer had resolved this already - he had callback hell, then rewrote everything to Promises. Await came out, and then rewrote back to Promises. Then rewrote everything back to callback. *Because it is just more comfortable* 😅

[@0xDEAD_Inside]

The second sentence should have "await" at the end.

[@juliocesar-fc1nm]

@@nosferratu Eveeerythiiiiiing. I wish I could post the mem photo hahah

[@kevinflorenzdaus]

haha sounds like the video from "Programmers are also human"

[@wbtittle]

Async/Await lesson curves. Make sure you put async in front of the function definition and AWAIT in front of where you want the code to stop until the await happens... Cool.. Then you are debugging the transpiled code. HOLY F... Look at this... callback helll...

[@rossbagley9015]

Senior JavaScript developer learned one of Java, C#, Go, or Rust and implemented his server-side code in a language more appropriate for the problem.

[@neociber24]

I mean, in an interview someone said that NodeJS use a single thread and the interviewer didn't believe it, a lot of devs think promises are multithreading

[@Fs3i]

That would be scary as heck. Imagine all the concurrency issues that would crop up, oh dear.

[@sergisimon9620]

​@@Fs3i couldn't they? If functions do not alter a global state then they should be able to be parallel, right?

[@chainingsolid]

If your going to go async you might as well go multi thread... so I would too expect it to be multi threaded.

[@Fs3i]

@@sergisimon9620 That's a big if. It's very easy to alter global / shared state, and then you deal with race conditions.

[@aeggeska1]

Yep. I had that happen this week. A dev thought that "async / await" was multithreading. Scary.

[@BlackAsLight448]

JavaScript will try and run async code as sync code until it hits a point that forces it to the back of the event loop. Meaning if you attach the async keyword to a function with no await keyword inside it, it will run in sync and never be placed at the back of the event loop.

[@mattymerr701]

A different way to say it is that it is cooperative multitasking. It only switches when the user code tells it to switch. It won't pre-empt that switch.

[@huge_letters]

Not sure if I like it or hate it - it's probably good for perf but boy is it unintuitive sometimes.

[@fardelian]

This is an extremely important detail, thanks for pointing it out. In the case of async functions which cache their response, the overhead is the JS engine creating a Promise object. Even if you write your code using async, if it can be executed in sequence without deferring to to the task queue, then it will be executed in sequence. Prime hates JavaScript, so he doesn't learn it and he doesn't understand it but he talks a lot about it...

[@huge_letters]

@@fardelian Prime understands JS very well and has been writing it professionally for years, in performance sensitive environments. He can still have misconceptions but saying that he doesn't (want to) learn it is absurd.

[@spicynoodle7419]

Not quite. If you return a promise form a function and don't await it, the promise will be placed on the back of the queue. So the rest of your code can't depend on the result of the promise. If you don't await the promise it's going to be a pure side-effect. Kinda useless, might be better to use background workers that run in a separate thread

[@tharsis]

To be fair, if SQL was actually SLQ, then it could be pronounced 'Slick' which I'd be a bit more tempted to use in speech than 'Squeal'

[@0xDEAD_Inside]

*Sequel

[@EricSampson]

or “sleek”

[@vcokltfre]

@@0xDEAD_Inside *esquill

[@FlanPoirot]

yeah it's sequel not squeal, idk why he pronounces it like that

[@rafaelbordoni516]

Call it squirrel 🐿️

[@iulianbojinca7309]

Bad programming is bad programming. Using callbacks can lead to callback hell with bugs and impossible refactoring strategies, while Promises lead to event loop starvation and slow performance. But honestly, I can deal with a misplaced async situation much more quickly than the callback hell.

[@Dylan_thebrand_slayer_Mulveiny]

You have no idea what you're talking about.

[@jaysistar2711]

Promises are not inheritly slower, just the implementation. C++ promises can be optimized away completly. Rust's futures are optimizable as well. If JavaScript is your problem, you shouldn't change styles to make your code unmaintainable; you should change your language.

[@razhemo4191]

surprised this isnt the top comment, this place is too full of frontend developers 😅

[@Dozer456123]

@@razhemo4191 You gotta make sure everyone's included

[@asdqwe4427]

The discussion was about JavaScript promises…

[@razhemo4191]

@@asdqwe4427 why limit the discussion?

[@dhanushc5744]

@@asdqwe4427 " If JavaScript is your problem, you shouldn't change styles to make your code unmaintainable; you should change your language."

[@AnupamAgrawal-q9u]

Thanks man , this helps a lot . We always got level up after watching your videos and you provide very good quality content . Anyone can create a video reading a blogpost but you discuss about it very well , explains the topic by keeping beginners in mind and taking about pros and cons of it . I rarely write comment but this is worth it 👍

[@aotein]

There's another cost: Not knowing computers or working together with other software ecosystems. I had to work together with another company, which based their GraphQL API onto a standard SQL server. They didn't know how to access the GraphQL-API without a framework (like the URL). They didn't know how documentation works at all. Their error handling was non-existing. Their database structuring was just one giant JSON and little thinking was done about how to access certain data points. I think the sole focus onto JS/TypeScript and resulting frameworks really hurts the knowledge of what computers actually do or how other software ecosystems should be able to interact with yours.

[@ES-eb6pb]

looks like 90% of people who learned graphql use it completely wrong! You should never do that for each loop and fetch each element of the array from IO! What you should do instead is Retrieve the query object the user sent, check if the array field is not undefined, and then build an SQL string that is performant and fetches what the user exactly requested. JUST CALL THE DB ONCE NOT A DOZEN TIMES

[@asdqwe4427]

And 99% don’t need to be using graphql at all

[@bilbobaggins7075]

@@asdqwe4427 that's like saying people shouldn't be using rest. it's just a standard, low understanding comment

[@asdqwe4427]

@@bilbobaggins7075 graphql is hard to get right. The flexibility is really cool if you have tones of different consumers. But most people have one frontend and then it’s way simpler to make simple api that caters to the use case the that you do have. Don’t make some generic solution that’s hard to make scale.

[@svetlinzarev3453]

Not possible when nested objects with paging is involved. That `... FETCH NEXT xyz ROWS ONLY` really kills it.

[@gabrielspeed5464]

​@@bilbobaggins7075no it's not... GraphQL is not a standard, it's a spec. GraphQL does not conventionalize anything.. There is no reason graph QL has it's own query language instead of just being a REST API accepting JSON ASTs..

[@IhsanMujdeci]

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.

[@JacobBogers]

Most coders are not coders, without a framework they are lost

[@gabrielspeed5464]

@@JacobBogers you're using Dart complaining about frameworks on a topic where frameworks aren't even involved (promises are native in JS) You don't even want to use Kotlin and Swift directly. The irony here is so sweet

[@JacobBogers]

​@@gabrielspeed5464 "you're using Dart complaining about frameworks" That is very trolly and dishonest claiming things I never even implied let alone said. But what to expect from an arrogant lazy POS, who cant even code.

[@dabbopabblo]

I avoid chatty protocols by just anticipating every action a users going to take before they even enter my site and serve them everything in the database in one request and make every possible change they might make at once before returning. Can't have a chatty system if you only use 1 request.

[@deidyomega]

No joke we actually did this for a client once. On site load, download the entire user's data locally. For our very weird use case, it actually ended up being faster.

[@chunkspiggle3916]

​@@deidyomegaThat's crazy, I'm rewriting an app that did not only exactly that but also leaked every other user's full data in every response from the backend (including their [encrypted] passwords!!! You could see it all by just hitting F12!) Changing that, on top of the UI changes my client wants, would require a rewrite of 90% of the codebase anyways so I'm redoing this horseshit in go+htmx+templ now lmfao

[@LucasLocatelli]

Funny that most of the issues pointed were not about graphql...

[@Elkemper]

You man, i discovered your videos just few weeks ago, and i wanna thank you. I'm quite hardened SDET and working with JS|TS more than 5 years (and few years on other langs before), but most of the time i worked as a lead on the-only sdet on a project, and i never had a buddy, with whom i can discuss js-related stuff, more to say, really deep-knowledged buddy. And your videos for me - it's a great pleasure to just hang out, learn very interesting stuff which i presumably will never use in my work , but it expands my view and understanding of the lang and tools. i hate reading tech literature, so everything that i've learned - is just experimenting and trying to code what is in my head. and i think i'm not the only one in this situation, and i hope more of someone like me will find your content helpful So please, explain more, show more, rant, but show how do better. Thank you.

[@yowwn8614]

That one time I used graphQL (unwillingly), after 4 months into development, I resigned because stakeholders didn't believe it was the bottleneck.

[@justADeni]

did you work at a startup?

[@deidyomega]

Graphql is only the bottleneck if you (or someone on your team) wrote a shitty gql server. Same with client side code. You can write a gql server in rust, with blazing fast speeds and none of the mem overhead. You can consume that graphql without any library, if all the libs are too slow. Or change your client lang. Write your gql client in rust, compile to wasm, then expose the entire thing to js as the glue if you need. gql is just a language, nothing in the language requires slow code.

[@Dylan_thebrand_slayer_Mulveiny]

You were wrong. Good thing you quit though. Saved them the hassle of having to fire you for incompetence months later when your assumptions destroyed their code base.

[@BobFrTube]

Since I mostly write code that is not extremely performance-sensitive, I have no problem using JS (or TS). In the day, I was a big C# user and appreciated values (integers, structs, etc.) didn't need to use the heap. Struct, in particular, is a useful way to reduce GC. I'm keenly aware of the cost of promises because, before promises, I implemented my own versions (in JS and C#) by creating an object to hold the pending state). How much are today's programmers aware of how these mechanisms are implemented? And why, for much code, readability is more important, but not always. As go graphql -- I've found SQL simpler, but that's another conversation.

[@Myself0094]

Nowdays C# makes some kind of black magic with Task state machine and even more one with ValueTask. The latter is specifically optimised to have minimal perf impact on cases where value is returned synchronously.

[@gro967]

GraphQL and SQL have nothing in common, you can’t compare them…

[@grimm_gen]

Ultimatly it all depends on what project you are working on! I have a preference for GraphQL over Rest

[@dhanushc5744]

I think the point of video is graphql is slow doesn't matter your preference or the project. Its very easy to write bad code with gql/js.

[@deidyomega]

@@dhanushc5744 gql isn't slow, maybe apollo's implementation is slow, js is slow, but gql isn't slow. There are rust implementations of gql that are crazy fast, and don't have the same insane mem overhead.

[@PwrXenon]

JavaScript on the backend is only cost

[@JeremyKolassa]

"When your tracking software slows down your entire universe, that's not good." Best description of the Heisenberg Uncertainty Principle?

[@LurajerLP]

Graph Kwil - You're a mad man

[@mosescosme8629]

That last rant about that code snippet was one of the most important things I think I've ever heard.

[@anlumo1]

If you care a lick about performance, why the hell would you use JavaScript in the first place?

[@etherweb6796]

Combine that with object prototype pollution and eval exploits it is just not a good language for server side at all. (And I like JS in the browser) It might even be worse than using PHP - if it has filesystem access.

[@Dylan_thebrand_slayer_Mulveiny]

@@etherweb6796 Everything you said is just word salad. You have no clue what you're talking about.

[@etherweb6796]

@@Dylan_thebrand_slayer_Mulveiny lol, ok, google "Object.prototype pollution" or "exploiting server side eval in JS" and use it as dressing for the salad then.

[@theairaccumulator7144]

@@etherweb6796 what are you even talking about bro? Did your bot break again?

[@aprilmintacpineda2713]

13:00 Hmmm not sure if I remember it right but I’ve tried this before, async functions that doesn’t perform an await operation does not get pushed back the queue, they act as though they aren’t async, the only time when the function gets pushed back the queue is when they do await.

[@SurenEnfiajyan]

But when they return, they wrap the return value in a promise, so at least one microtask is added. I think the morale is to avoid using async functions if you don't need to. Async functions are fine for slow IO operations such as db queries.

[@AqgvP07r-hq3vu]

"Are callbacks really async if your date never does them?" He got me

[@ark_knight]

I mean thats definitely not in sync, or else there would be a callback. from your date.

[@jerrygreenest]

«GraphQL gives you a promise of easy...» But the promise part is hard, it adds some CPU overhead, it seems.

[@rabbitcreative]

20-years in the industry and all I have to say is, "I told you so".

[@clamhammer2463]

I jumped on the async bandwagon and was ALL about it. EVERYTHING was async. Then my project got large, and the mental debt was so significant. ONLY use it when you truly need asynchronous code. It doesn't need to be and shouldn't be all or nothing. For example, if you are writing logs to a file, that can be async to not block the app's execution, which is a good practice. However, using async for every operation, especially in larger projects, can lead to issues like race conditions and increased mental overhead. Therefore, it's essential to use asynchronous code judiciously, where it provides a real benefit, and not make everything async 'just because.' This balanced approach ensures a more maintainable and efficient codebase.

[@freeideas]

Or you can use java virtual threads, which are simple -- i.e. no promises, no callbacks; no async/await, and get all the scalability benefits of microthreading. Instead of constructing C so can give it to B as a promise or callback, then give B to A; in java you just do A,B,C.

[@lionbryce10101]

Aren't Promises just roided out callbacks? Like Object-Oriented callbacks. Except roided out ends up meaning way slower

[@jimhrelb2135]

Callbacks as continuation-passing style (CPS) + sane compiler = Callback heaven (ref: tail call optimization and cps basically turns unbounded recursion -> iteration) Callback as CPS mechanism + no actual compiler = callback hell

[@rodrigolj]

“My favorite type of tweet is the one where everybody loses.”

[@hannessteffenhagen61]

With the memory thing, this is why garbage collection gets such a bad rep. It's not that garbage collection is slow. It's creating all that garbage in the first place that's making things slow! The garbage collection part is just where you end up realising the cost. Kinda like blaming some code for dereferencing a nullpointer when it shouldn't have been passed one in the first place.

[@FalcoGer]

There is nothing hidden about the cost of node js. it's literally in the name. java script. the cost is that it makes you go insane from how awful it is. It was bad enough that it became the web standard for scripting. Whoever thought it was a good idea to use javascript for backend and non web application needs to be imprisoned for life.

[@ImaginaryNumb3r]

This is also not a hot take. It's just how it is.

[@conorx3]

I wonder if there is a hidden benefit to Node.

[@andreapigatto2762]

I guess Node was born when your only alternatives were Python (slow), java(verbose) and c++.. I would go with node for sure having just these alternatives if I would need an api for a web app written in JavaScript (vanilla or any other framework)

[@geoffclapp5280]

​@@andreapigatto2762 PHP was plenty fast enough in 2010 for most web apps.

[@blvckbytes7329]

​@@andreapigatto2762Well, node basically appeals to people who want to build something but are not willing to invest the time and effort to learn more than just the surface of the iceberg. "It just works." I don't at all get why so many "professionals" are highly paid to use it. Seriously, if you have been in the software engineering game for over a decade and don't know enough to make your project happen in a proper language with a proper framework, you've wasted your time. But as long as there's no customer that's being ripped off with poor performance but not so poor project costs, it's fine. To each their own.

[@anarchymatt]

I think the problem here is using js on the backend, not as much graphql

[@tanmaytiwari2450]

Really good explanation we need to keep this in mind. I had one thought how are Observables and Subjects vs Promise

[@jackdanielson1997]

Oh no, I might get a 5ms delay if I'm getting nested data for 100 users. Shucks, I guess I should optimize that when the db queries are taking up 400ms and the network latency is 100ms

[@mattius17]

The rant about "x" reminds me of Yahzee (of Zero Punctuation) calling tweets "excrements" now 😅. Epic video Prime

[@gonzalomunoz2767]

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?

[@jeffreysmith9837]

Promise object has an overhead, idk the details

[@Dylan_thebrand_slayer_Mulveiny]

@@jeffreysmith9837 It's just a pointer to the promised function and a flag that denotes whether said function has been invoked and concluded. Next to 0 overhead involved as opposed to just running the function immediately.

[@HrHaakon]

The two selects he's referring to at 9:51 are the SELECT stuff FROM users WHERE id = ?, and SELECT stuff FROM items WHERE userid = ?. So he's saying that you can do that roundtrip in < 100 ms, which is true, but if it's only 10 000 items, then the ping-ponging to and from the db is a significant source of time. I remember when I did 500 inserts and THEN committed, vs doing 500 insert + commits, and how the whole thing went from seconds to milliseconds just like that. In my defence, I tried, saw bottleneck, and THEN made the batch inserts, which are a bit more complicated in that the code will look a bit different.

[@gwaptiva]

I wonder how big this application's access log is.. and how big the disk it lies on.

[@jfftck]

So, the fix is to implement a new task keyword that does real threading to functions in JavaScript.

[@idkidk9204]

Meanwhile me happily using threads, async and such noice stiff like this in c# without any drama

[@CarlosEstebanLopezJaramillo]

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...

[@blender_wiki]

N+1 issue can be solved easily by hiring a descend developer or using a good ORM if you can't find one.

[@CarlosEstebanLopezJaramillo]

@@blender_wikiIndeed, just saying Neo4j has the solution embedded in their GraphQL library, so I don't even need to think about it :)

[@neptronix]

Interesting, i was wondering why nodeJS is 3x slower than PHP with swoole, despite the fact that it was built for async first, and async behavior in PHP was very after the fact. That's some serious computational pork!

[@W1TEA]

yet another 'I built a benchmark that shows.....writing with chisels on stone tablets is faster than Rust, Go, C, and Commodore Basic"

[@AshtonMotana]

Maybe stop using foreign keys to join nested items with a parent data model. Instead, capture the parentID in the item and find all items by the patentID field, and directly query the items. No need to query the user just to get the users' items. Doing this then removing .populate('userItems') from the user resolver will speed up the server respons. My limited experience and this observation tells me to avoid joining on nested lists. I had a query contacting a resolver that had. populate('userItems') the GraphQl query wasnt requesting the items and ther server wasn't sending the item. The .populate still causes your server traverse the data and smow its response to the client.

[@hanabimock5193]

it is incredible that this channel monetises reading blogs.

[@shreyash1]

exactly

[@wbtittle]

Thank you. This explains so many of my current issues...

[@wbtittle]

Cut and Paste might be ahead of this... But when people cut and paste async await with tracing all over the place...

[@fredrik8737]

NodeJS threads comes from making a another request to another NodeJS instance. Don’t do all the the work in GraphQL resolvers if that’s slow, feature flag, auth etc

[@thewiirocks]

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".

[@vukkumsp]

When I first learned about graphQL, I thought it was efficient until I saw the resolvers 😅, it just looks simple to use graphQL API but the actual API implementation is very inefficient.

[@Kurimson]

What library would you suggest over express? I've always thought of express as the standard go to and never questioned its performance. I mean everything I've ever used it for seemed fast.

[@maltbiscuit9995]

Yeah that's what I am thinking. I got a nice React, Apollo and Mongo stack going on here. It's a great package to bring stuff to market and try things out.

[@jeffreysmith9837]

It is the standard for node but node sucks. Poor performance, fake types, and has no backend ecosystem.

[@AmatuerHourCoding]

Nestjs with fastify. If performance is that serious, golang. If you aren't having performance issues then don't worry about it 🤷 Instagram runs on Python so its not that serious

[@Dylan_thebrand_slayer_Mulveiny]

Promises are just a function that run sometime in x event loop cycles. There's literally no difference in performance. The only benefit is that you aren't waiting for them to resolve before other code executes. Anyone arguing about the "performance overheard" of promises clearly doesn't understand how Javascript works, what a closure is or how pointers work.

[@mileselam641]

"But GraphQL is complex!" Use Postgraphile "But the SQL it generates is slow!" Use Postgraphile "And avoiding N+1 in resolvers is hard!" Just use Postgraphile

[@varshard0]

But then you would be programming everything in SQL with Postgraphile and putting business logic in SQL. Also anytime you want to make a tiny change to your function, you would have to create a new migration file and make it hard for a version control to show what's actually changed.

[@mileselam641]

@@varshard0 Postgres supports idempotency in DDL. CREATE OR REPLACE FUNCTION foo() … Put that in an SQL file and re-run as often as you need to. Always ends up in the same state. Structural changes to tables is harder, but that's no free lunch in any workflow. ALTER TABLE IF EXISTS foo ADD COLUMN IF NOT EXISTS bar int4 NOT NULL DEFAULT 0; Fast for adding the new column. Free when the column already exists. Idempotent SQL. There's your diffs and version control. DB schema *is* business logic. Algorithms have always taken a lower priority to data structures among top coders, and databases are nothing if not data structures. "But the API shouldn't leak the DB schema." 1. 99.9% of the time, the API and schema are the same, especially with most ORMs. 2. You can always just make a new schema and define views to reflect your API. 3. Defining the DB schema bubbles up so you don't have to redefine records and types again at the API server level and yet again at the UI consumer layer. Starting in the middle of your stack compromises the whole stack; your DB structure gets compromised by the impedance mismatch, and your development cycle gets compromised by writing all your types manually in triplicate. You're right that Postgraphile introduces some complications to typical dev workflows, but let's not pretend our current dev workflows are smooth and seamless as they are. Better to err on the side of clean and uncompromised data structures. But if Postgraphile isn't to your liking, there's also Hasura. Point is, life's too short to be writing object definitions in triplicate only to hamstring you DB's performance. Focus on the DB structure, and you've fixed most performance and workflow problems before they even start.

[@mileselam641]

@@varshard0 "Bad programmers worry about the code. Good programmers worry about data structures and their relationships." - Linus Torvalds

[@felipedidio4698]

Oh, I get it. If you write garbage code, the garbage collector has to work harder.

[@asoftyn4805]

What if you loop the fields in the querry but do smth like a querry builder so we only get 1 promsise for all of the required data?

[@pedropertino7324]

hey man i've always loved your content, but i think your reasoning about promises is wrong, that is the bases of concurrency (sharing the resources instead of hoarding them), you would have the same issue with callbacks (even if things are not actually async, you would stil steal the resource while doing your sync stuff and other requests would pay the price, you just moved the issue to somewhere else, not fixed it). my guess is (from what i've notices) that when promises are already resolved (the cache you mentioned, but also it can happen when reading a huge directory without throttling ) the list (which im pretty sure is an array) becomes too big and inefficient for pushing/popping elements from it. await also counts as 2 promises either way (each await), thats why `await null` does not throw, because you are technically doing `await Promise.resolve(null)`

[@Ked_gaming]

There's so many things wrong with the approach I don't even know where to start

[@TheRcfrias]

is there any evidence which confirms that promises-async/await are slower the callbacks?

[@rossbagley9015]

So, isn't the conclusion to use a more suitable server-side language for GraphQL/REST/complex business logic/everything on the server side? Unless you're trying to bang out some sort of prototype or tiny one-off site...

[@outwithrealitytoo]

The lesson is, I believe, use technologies that allow you to do more work in the database. What is killing Node here is the chatty protocol, but the chatty protocol is the primary problem. This leads Node to bow out early in the scaling game but alternative solutions based on the same protocols only scale in the sense that "you can pay for double the compute and ten times the network capacity than you could if you didn't use naive database abstraction libraries, but it will at least work (unlike Node)". Node is a canary in the coal mine for the underlying issue.

[@KyleHarrisonRedacted]

I wrote a processor in php5 that handles taking in Madcap Flare static website exports in archives, doing a lot of post processing on the HTML across sometimes thousands of pages, to convert them into database records. When it was noted that it just runs too slow, my first thought was To rewrite it in Node (being able to batch process pages instead of one at a time was appealing, as well as jQuery on the server to handle the DOM editing was super appealing) I got HALF way through the writing the processor when I noticed it already ran slower than the php5 edition on the same export. That’s when I learned how awful mode is at dealing with the file system, and how weirdly terrible nodes concurrency really was. Then I posted the php5 edition to php7 (15 minute job) as the old one was now 27% faster on average runs compared to the 5 edition and used a lot less memory, was a well timed slam dunk. I’m back to rewriting that processor in Rust as I write this.

[@spicynoodle7419]

Port it to PHP8.2, enable JIT and watch it become 40% faster. Parsing HTML is inherently synchronous so Node won't help you at all. Even if you write the funny async keyword in your function signatures, they are gonna block the event loop completely. This is a job for threading, not concurrency

[@SlawomirBudzynski]

If it's about optional async function it doesn't work as you've mentioned at least in Chrome browser. I was a little surprised this some time ago when I've found that async doesn't equal setTimeout(cb, 0). async function test() { console.log(1); }; test(); console.log(2); Will return: 1 2

[@natedavidoff668]

At this point programmers don’t really know how anything they are coding works behind the scenes.

[@u9vata]

Omg, they lost me at not wanting to use JOIN in SQL by default but separate calls. I honestly start to think abstractions, styles and such were all bad ideas as they are "guidelines over thinking"... but one cannot really avoid thinking otherwise result will be bad....

[@andreicalegari1837]

Even the people who made Express know how bad it is

[@MuhammadTajammulZia]

Sarcasm so strong I can never surely say which technologies he works with..

[@aelsayed313]

Arent promises resolution microtasks? In the video he illustrates that they are tasks

[@pedroaugusto656]

Sorry but how aren't promises just callbscks ? I always thought they were the same kust written different

[@adesanoyesamson668]

Am on the team write SQL instead of using ORM. use ORM if performance not involved

[@Brian-ro7st]

As a node dev, I don’t claim anyone who prefers promises to async/await

[@maplepenguin8568]

Are Promises without using the async and await keywords still problematic?

[@pkop4]

Yes, async await is just syntax sugar for promises. As he described every ".then()" is incurring the costs he's describing as well

[@mattymerr701]

Mercurious. People who are interested in merpeople but not fully sure about it yet

[@NatoBoram]

Ah, fuck callbacks in Node.js. I'll just take the L in performance, the maintainability is well worth it. If I wanted big performance, I would just write it in Go.

[@dovh49]

I wrote a library for declarative validation. It uses promises so it can be declarative, like so: ```js var { my, data } = await validateObject(data, validator) ``` It works great. But apparently it uses a lot of memory? Well, my apps are simple, I don't care. I just like the easy way to validate and not have to return early, just let the promises do everything for me. But if I need to have more performance I'll keep this video in mind.

[@maxlife459]

19:30 heh, I typed that :P

[@StingSting844]

Isn't this solvable using Dataloader?

[@JessicaS-dl1fs]

This whole vid showed an incredible lack of understanding of programming in general and js and node in particular

[@Saiphes]

"Functions are people" -- primeagen, probably

[@gund_ua]

Someone tell this man that Promises resolve in a microtask queue and NOT in the task queue where all other timers go! It's a huge difference and it will not put your promise resolved callbacks at the end of your other incoming requests as microtasks are drained at the end of each tick, not in the next tick lol Also please stop concerning about memory, nobody wins when you do, compilers and runtimes know best how to organize memory best. As someone said it best - you should write semantic and idiomatic code which uses language as it intended and not try to workaround it.

[@WolfgangJules]

All the things mentioned here about promises and nodejs are true, but i think nobody point out the most important issue here, the SQL knowledge, because one single query can solve all this mess here: SELECT i.* FROM items as i INNER JOIN user_items as ui ON i.item_id = ui.item_id WHERE ui.user_id = @user_id; BTW: The fact the coder is using the user table like user_item table, point out to another problem: "database normalization" because, in this example the right thing is have at least 3 tables: user, items, and user_item (items purchased by the user)

[@Tom-jy3in]

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...

[@jeffreysmith9837]

Isn't that normal? The event loop is single thread but async operations do work on worker threads.

[@ShakhorSmith]

They don't even know basic SQL I can't take this article serious

[@vitorguidorizzzi7538]

They did the weird no join query so the SQL generated by the graphql+dataloader was the same used by the rest version.

[@wepranaga]

well in this case callback doesn't help, cause callback still pushes to the task queue to wait for the event loop to pick it up. this video just the hidden cost of the event loop in javascript. and graphql is exacerbated it with N+1 and async field resolvers. even so, the db calls promise and callbacks won't start populating the task queue until its done. the bottleneck would be the event loop picking up each task one by one to be executed in the main thread. unless the event loop should spark another thread to execute the callback but had to share context, variables, etc with main executions you could argue to use a language that doesn't have task queue. but really how would you blame a literally single-threaded language that happens to have a non-blocking task-queue to handle async operations I agree that needlessly adding async to a function would cause unnecessary round trip into the event loop to execute your code instead of doing in synchronously in the main thread

[@JarrodNotJared]

do a vid where you optimize the code you showed at the end

[@hipertracker]

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.

[@LulaTheStampede]

by the time they fix this there'll be another framework out where this isn't even a problem

[@renatocustodio1000]

Isn't this basically the n+1 problem at an API level?

[@leaf1208]

If I hear this man pronounce "GraphQuel" one more time istg

[@overbyte]

Orms are like graphql - fast to get a prototype running but with massive tech debt later on in mature software

[@outwithrealitytoo]

Controversially I'm going to say "it's not a speed thing, it's a skill thing". With ORMs/Graphsql you can get a naive prototype running with people with a light understanding of data and no SQL. However, as the transaction number and data volume increases, and as requirements change requiring data migrations occur; so it is that staff with greater knowledge of data are required. When it is time to scale, if you start with skilled developers and don't go down the data-framework rabbit hole then all you need is a bolt on DBA. If you went down the rabbithole then a) your devs have probably taken flight b) you're new staff are going to have the joy of migration c) a DBA won't be able to help much until the code is sorted. Sometimes "time to scale" is just moving from dev to prod ... insert burning house meme here

[@thekwoka4707]

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.

[@kaos092]

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.

[@flamendless]

I wonder if this dataloader promises issue also affects django + graphene

[@pbkobold]

Oh it does. Badly. Every time I have to debug the implementation’s ‘promises’ port to Python, it feels like getting hit in the head.

[@flamendless]

@@pbkobold so more or less it has something to do with the implementation of async (event loop)? In my case we use gunicorn. I'll read about the implementation of that

[@chauchau0825]

I feel sad it took that many years for people to figure this out

[@DelPieroJoga10]

Node means love

[@malcolmhutchison]

The Structured Languages for Queries (SLQ) should of course be pronounced as "slick" ;)

[@chirale]

I'm concerned about NodeJS projects maintainability in the long run.

[@dwiatmika9563]

Yes, it has the worst ecosystem by miles

[@grumpylibrarian]

My general response to complaints about JavaScript performance is why are you writing performance-critical code in JavaScript. But I do see the case to be made from this video that it would be nice to at least have a means of prioritizing some promises over others. There might be a way to create a priority queue that can intelligently decide which .then() should be called next.

[@لوسيفرجبريل]

What is the name of the drawing software he was using?

[@magfal]

6:46 i wonder how Graphile would perform in comparison

[@MyGroo]

"the hidden performance cost" plot twist - it's not even hidden

[@hey_james]

The hood, the fucking good, why did you make it your thing?? Is it like your comforter?

[@georgehelyar]

Do JS promises really continue asynchronously even when the promise is resolved immediately? I'm not a js dev (thankfully) but when I've actually needed that behaviour in the past I've had to use a setTimeout(0), even with promises.

[@SurenEnfiajyan]

When you resolve the promise immediately, the callback passed to then() method is not called immediately. Promise.resolve('async').then((v) => console.log(v)); console.log('sync'); this code will first print 'sync' and then 'async'

[@outwithrealitytoo]

They don't "continue" they pause and cede control to the main loop, before being restarted when they hit the top of the queue. It has the advantage of stopping the processing getting lumpy at the cost of performance. i.e. on average responses take a little longer, but none egregeously so. Lumpy (jitter) data processing is painful because it shows with the frequent short messages taking way too long, rather than with the occasional long running culprits. ( it's analogous to a sleep(0) if you are using a real-time micro-kernel.)