gitpay icon indicating copy to clipboard operation
gitpay copied to clipboard

[BE] Use native node.js promise

Open alexanmtz opened this issue 7 months ago • 26 comments

✏️ Summary

Replace Bluebird promises for native js promises in all modules

📋 Description

We're using Bluebird promises in modules like here: https://github.com/worknenjoy/gitpay/blob/master/modules/users/userAccount.js, and we want to replace with native JS promises as discussed here: https://github.com/worknenjoy/gitpay/discussions/978

We have a lot of API tests, so the tests should continue to pass, and no extra tests are needed for this.

🔍 Steps to Reproduce (or trigger)

  1. Run the project locally
  2. Run the Node server
  3. Run the front-end server
  4. Create a user

Check how to run the project locally here: https://github.com/worknenjoy/gitpay/blob/master/README.md

✅ Expected Behavior

The tests should continue to pass, and the platform should continue working as it is today

🛠️ Stack Affected

Node.js

💰 Is there a bounty for this issue?

No

📜 Bounty Details (if applicable)

This issue is not part of our bounty program and you should work on it as a contributor.

For starter contributor, it could be a good chance to get your PR reviewed and get some experience

alexanmtz avatar May 15 '25 11:05 alexanmtz

assign it to me @alexanmtz i will do this : )

rogdevil avatar May 15 '25 11:05 rogdevil

Great @rogdevil , I will assign to you

alexanmtz avatar May 15 '25 12:05 alexanmtz

@alexanmtz can we use async await instead promises or there is specific use case of promises

cipherravi avatar May 16 '25 06:05 cipherravi

@alexanmtz can we use async await instead promises or there is specific use case of promises

Using async await or promise are dependent on how you want the flow to be if u want blocking flow u use async await if u want parallel execution u can use promise .... What you cannot do is replace promise entirely with async await. PS: async await is built on top of promise

Let me know why you feel async await is better subjectively

rogdevil avatar May 16 '25 06:05 rogdevil

for better readability i guess and if there is any reason to use promise then only we should use like promise.all or something

apart from this i am facing issue to start frontend server , backend is working but frontend has some issues i guess dependency issues what best i can do to tackle

cipherravi avatar May 16 '25 06:05 cipherravi

@cipherravi For issue related to running code please open a new Issue

as for readability again I would say it depends on the how you use it personally I wouldn't want to replace,

const getLatestTransaction = () => getCurrentUserID()
  .then(getUserFromID)
  .catch(handleNoUser)
  .then(getUserTransactions)
  .catch(handleNoTransactions)
  .then(transactions => transactions[transactions.length - 1]);

with

async function getLatestTransaction() {
  let user;
  try {
    const userID = await getCurrentUserID();
    user = await getUserFromID(userID);
  } catch (error) {
    user = await handleNoUser(error);
  }

  let transactions;
  try {
    transactions = await getUserTransactions(user);
  } catch (error) {
   transactions = await handleNoTransactions(error);
  }

  return transactions[transactions.length - 1];
}

you can write readable code in any format if readability was so much of an issue for you in above syntax I think u should focus on Javascript basics again

rogdevil avatar May 16 '25 07:05 rogdevil

we don't write code for ourselves only we write for everyone and code readability should be our first priority , machine can even understand binary

cipherravi avatar May 16 '25 07:05 cipherravi

@cipherravi I agree but I have a question for you what is unreadable in the code I texted above, i feel u have a tunnel vision and you do not understand at the core why things are, u read somewhere that do not use promise and use async await instead and now u are stuck with that, using async await vs promise do not increase code readability because just like you there will be someone out there who will be saying that using promise make code more readable "CODE READABILITY IS SUBJECTIVE AND YOU CAN WRITE CLEAN CODE WITH BOTH ASYNC AWAIT AND PROMISE YOU CANNOT SAY THAT ONE IS BETTER THEN OTHER"

I think u should really need to read Javascript again https://eloquentjavascript.net/ here is a good resource

rogdevil avatar May 16 '25 08:05 rogdevil

Thanks for your resource but i have read that book and i have worked with callback and promise and iterators generators and also async await and by chaining method we can create Pyramid of doom for there async await helps more than Promise. that's why Async await created

cipherravi avatar May 16 '25 08:05 cipherravi

so you are saying that every time u use promise it will create a "Pyramid of doom" thus async await is better ???? I can't argue with that u need to learn a lot u don't know how to write code yet this will be my last comment for the discussion

rogdevil avatar May 16 '25 08:05 rogdevil

In short:

  • Use async/await in production code — it's better for readability, maintainability, and handling complex asynchronous flows.
  • Promises are still the underlying mechanism, and sometimes useful directly (e.g., Promise.all()), but async/await is preferred for most use cases.

Why async/await is better:

  • Cleaner and more readable, especially for sequential logic.
  • Easier to write and debug than chained .then() calls.
  • Works well with try/catch for error handling.

When to use raw Promises:

  • When you need parallel execution (e.g., Promise.all, Promise.race).
  • In lower-level libraries or utility functions.

Recommendation for production: Use async/await by default; use Promises directly only when it makes the code clearer or more efficient.

I think i also said same but someone recommend me to revise my basics , Thankyou for your time and i am also busy in making personal project .

cipherravi avatar May 16 '25 08:05 cipherravi

@cipherravi I know when i see a LLM using kid thats why I told u to read again ... find me a documentation that says Use async/await in production code — it's better for readability, maintainability, and handling complex asynchronous flows. what you are doing here is bending the context and saying that everytime u use the promise it will result in a complex unreadable code so use async await. Read the following docs and have a open mind towards programming approaches u will go a long way instead of using LLM to prove your point

point 1: https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Async_JS/Promises#summary no where in this MDN doc they say u use async await instead of Promise

point 2: In the End of official MDN docs there is a article https://pouchdb.com/2015/05/18/we-have-a-problem-with-promises.html, In this article this guy explains how people like you don't understand the programming patterns and say that Promise are not good

So again @cipherravi GO READ SOME DOCUMENTATIONS BEFORE ARGUING ON THE FORUMS IT WILL MAKE U LOOK LIKE A CHILD AND DO NOT USE LLM TO PROVE YOUR POINTS

ALSO FROM THE DOCS Keep in mind that just like a promise chain, await forces asynchronous operations to be completed in series. This is necessary if the result of the next operation depends on the result of the last one, but if that's not the case then something like Promise.all() will be more performant.

rogdevil avatar May 16 '25 10:05 rogdevil

@rogdevil First of all i can see in your eyes you are defeating here that is why you are using term like Kid for me you cannot prove it that promises are better for production if there is not need of promise.all or settle ...

And LLM are built on dataset which you can't read even if you give your whole life so they are more accurate than you in theory.

And the text book which you refer eloquent javascript , here are some lines from it

Even with promises, this kind of asynchronous code is annoying to write.
Promises often need to be tied together in verbose, arbitrary-looking
ways. To create an asynchronous loop, Carla was forced to introduce a
recursive function.

For most asynchronous code, this notation is more convenient than
directly using promises. You do still need an understanding of promises,
since in many cases you’ll still interact with them directly. But when
wiring them together, async functions are generally more pleasant to
write than chains of then calls.

so by your one reference i gave you your answer and we were debating about readability and clean code

And the doc you attach by saying i should see that is of year 2015 when async await is about to come and the author talks about benefits of Promises against callback not against async await but you lol miss the part . So childish at least do some research before telling anything

In the end i would say that accept that you were wrong about the fact that in terms of clean code , readability Async await is much better than Promises

All your sources were bullshit and Childish

cipherravi avatar May 16 '25 11:05 cipherravi

Well life will teach you nevermind .. there is a difference between word "convenient" and "better" and I will still say ... You can write clean code both using Promise and Async await ... Its just some people lack knowledge to criticize one over another and you are one of those

rogdevil avatar May 16 '25 11:05 rogdevil

Just simple question why Async await came if everything was going good with Promises

Give mature answer only

cipherravi avatar May 16 '25 11:05 cipherravi

@alexanmtz Can we use async await instead of promises, or is there a specific use case of promises

Using async await or promise is dependent on how you want the flow to be. If u want a blocking flow, u use async await; if u want parallel execution, u can use promise. What you cannot do is replace promise entirely with async await. PS: async await is built on top of promise

Let me know why you feel async await is better, subjectively

Yeah, @rogdevil, we want to use async await instead. This is using promises because it's an old implementation. Other new modules are written using async / await.

It's good to see some discussion regarding this subject, but yeah, we found out that promises chained can be a little messy as they become increasingly chained, and we are moving to async / await.

But you don't have to do this now. First, let's migrate only the top-level function to use native promises, and we can have this refactoring in another issue.

alexanmtz avatar May 16 '25 11:05 alexanmtz

Just simple question why Async await came if everything was going good with Promises

Give mature answer only

it came coz people fell into the trap of long promise chains so it was hard for them to debug so JS guys introduced async await but the definition clean code is still subjective to who is coding
for example - python is easier to learn and does a lot of abstraction for you to write simple code what will take u 8 lines of code in C u can do that with 1 line in python but when u need C u will use C not the python. You cannot say C is bad to use and one should only use Python it depends on the usecase ( I used this example because under the hood python uses C written libraries ) my first comment was in the same context I said none of them are superior Using async await or promise are dependent on how you want the flow to be if u want blocking flow u use async await if u want parallel execution u can use promise I never said that one is better than the other u need to see the situation to use one and if your only reason to hate Promise based approach is its difficult to understand then u need to brush up the basics, I use async await all the time but that does not make promise a bad choice does that clear it @cipherravi ?

rogdevil avatar May 16 '25 11:05 rogdevil

I also said as python cannot do C work same when talking about parallel execution we should prefer Promises not all time we should use async await as much as possible .

And i know my basics and when i face situation where Promise is necessary i will use that , i am not fan of any language or tool . I am a engineer and engineering concepts are same every where .

And at first i asked is there any specific reason we are using Promises bcz i didn't knew the codebase so i might be wrong .

Let's End the Discussion Here , Best wishes to you for your future journey

cipherravi avatar May 16 '25 12:05 cipherravi

any progress on this @rogdevil ?

alexanmtz avatar May 27 '25 10:05 alexanmtz

@alexanmtz can i work on this issue ?

Dheeraj4103 avatar Jun 08 '25 07:06 Dheeraj4103

@alexanmtz can i work on this issue ?

Yes @Dheeraj4103 , I will assign to you

alexanmtz avatar Jun 08 '25 19:06 alexanmtz

@alexanmtz I will work on this on weekends.

Dheeraj4103 avatar Jun 10 '25 03:06 Dheeraj4103

@alexanmtz will I get bounty this time for this :)

Dheeraj4103 avatar Jun 23 '25 15:06 Dheeraj4103

Hey @alexanmtz, I want to work on this issue. I will give my best and resolve it as soon as possible. Please assign this task to me !!!

GHANGHASASHWANI avatar Jul 07 '25 16:07 GHANGHASASHWANI

Hey @Dheeraj4103, no bounty for this one.

So I guess I will assign it to someone else, and you can always look for issues with bounties on Gitpay, but we don't have any right now.

alexanmtz avatar Jul 07 '25 20:07 alexanmtz

Hey @alexanmtz, I want to work on this issue. I will give my best and resolve it as soon as possible. Please assign this task to me !!!

Yeah @GHANGHASASHWANI I assigned to you.

alexanmtz avatar Jul 07 '25 20:07 alexanmtz