Why create a new Node-asana SDK?

English Forum Developers & API
1

Hey!

Why have you changed the node sdk? You went for callbacks instead of promises? Cant figure out why you did this change. Gonna be horrible to switch over. Please explain the reason its all changed?

2 Likes
2

I started to migrate, found a few minor bugs, and decided it was not worth it to update my dozens of scripts :sweat_smile: the syntax is completely different, the search service doesn’t work the same way, that’s a lot of work.

3

Hi @Jonas_O ,

Thanks for your message.

We recently took on an initiative to automatically generate our SDKs from our OpenAPI spec. This was done with the goals of keeping our SDKs up to date and eventually supporting more languages.

Our recent node SDK v2.0.x releases were generated with callbacks. We’re currently gathering feedback on that version (including callbacks vs promises) and plan to release an update which incorporates that feedback. In the meantime, we’ve updated our documentation to indicate that v2 is still in beta, and we won’t be limiting access to v1.

Thank you so much for your feedback! Let us know if there are other changes you’d like to see in a future release.

@Bastien_Siebman ,

Thanks for letting us know about the bugs you found! Will contact you directly to get details and make sure they will be resolved in our upcoming release. We’re also planning to publish some documentation to help with migration. We plan only to make updates to v2 (including support for new endpoints), but if you have projects which will largely remain the same, it might not make sense to spend the time upgrading.

4

Ok got it!
Yeha this 2.0 version is so completely different. And alot of stuff that we took for granted in v1 seems to be gone. Like the hold of and retry if rate limit is hit.

Nice to hear that it is in beta though because it looks messy with callbacks and I would prefer promises. I liked the old version of the sdk. It was really easy to work with. Made development fast. I hope you rethink it and go to promises based instead.

5

Wasn’t it embedded in the code? Are you saying this is gone entirely?

Why?

6

Well because of i dont want to nest callbacks… You know callback hell? And you have to do error handling within the callback of the function. I just like the cleaner code with try catch as most of us do. I dont even feel i have to defend that stance.

2 Likes
7

Promises are often considered better than callbacks for several reasons, which contribute to improved code readability, maintainability, and error handling:

  1. Improved Readability: Promises use a more linear and readable code structure compared to nested callbacks, especially in scenarios with multiple asynchronous operations. Promises make it easier to follow the flow of asynchronous code.
  2. Chaining: Promises allow you to chain multiple asynchronous operations together using .then(). This makes it clear and concise to express a sequence of actions to be executed one after the other.
  3. Error Handling: Promises provide a standard way to handle errors using .catch(). With callbacks, error handling often involves multiple nested if statements or try-catch blocks, making it harder to manage and prone to mistakes.
  4. Avoiding Callback Hell: Nested callbacks, also known as “callback hell” or “pyramid of doom,” can become difficult to manage as the codebase grows. Promises help mitigate this problem by allowing you to flatten the code structure.
  5. Guaranteed Asynchronicity: Promises always execute asynchronously, even if the operation is already complete. Callbacks don’t have this guarantee, which can lead to unexpected behavior in some cases.
  6. Easier Flow Control: Promises provide methods like Promise.all() and Promise.race() for handling multiple asynchronous tasks. These utilities simplify common control flow patterns, such as waiting for multiple operations to complete or selecting the first one to finish.
  7. Error Propagation: Promises allow errors to propagate through the promise chain, making it easy to catch and handle errors at a higher level in the code. In contrast, with callbacks, error handling is often scattered throughout the code.
  8. Composition: Promises encourage code composition and reusability. You can create reusable promise-returning functions and use them throughout your codebase, promoting a more modular and maintainable architecture.
  9. Support for async/await : Promises seamlessly integrate with the async/await syntax in modern JavaScript/TypeScript, which further improves code readability by making asynchronous code look similar to synchronous code.
  10. Promises are a Standard: Promises are part of the JavaScript language standard, which means they have built-in support in most modern environments. Callbacks can vary in implementation and conventions, leading to inconsistencies and compatibility issues.

In summary, while callbacks are a valid approach for handling asynchronous operations, promises offer a more structured and maintainable way to work with asynchronous code. They have become a standard in modern JavaScript and TypeScript development due to their many advantages in terms of code clarity, error handling, and overall developer experience.

4 Likes
8

Hi @Jonas_O and @Magnus_Ostlund,

Thank you for echoing your feedback about callbacks vs promises. We took this into account and released a v3.0.0 version of our Node.js client library yesterday that utilizes promises. We also talked to @Bastien_Siebman about the bugs Bastien encountered and changed our implementation to fix those issues.

Feel free to give this new library a try. Here’s the GitHub page for our node-asana library. Let us know if you have any feedback that we can incorporate in future updates.

NOTE: we are calling this a “BETA” until we have more confidence in the stability of the new library.

4 Likes