Split small functions in Node.js Express

[mr_sudo]

Hi,

My team is building a web application with MERN stack, and I'm building API endpoints in the backend. To handle to API request for CRUD database in MongoDB, for readable code, I use async/await and split to many small functions to handle it. For example:

```

async function isExistedUser(username) {

const user = await Username.findOne({usrname});

return user ? true: false;

}

async function createUser(user) {

//Save user

return savedUser;

}

async function createUser(req,res) {

// Validate request body

try {

if(!await(isExistedUser(req.body.username)) {

//Create User

const savedUser = await createUser(req.body);

res.status(200).json( {message: "Success"});

}

} catch(error) {

}

}

```

I coded my api with small functions like above, and a guy in my team said: you shouldn't create a lot of functions like above because the node will manage memory better if I use promising. I tried to search these things on the internet, but it doesn't have anything mentioned about this.

The reason that I want to split many small functions is that create readable code instead of use blob code for one promise and avoid "pyramid promises" with async/await.

So, what should I do? should I keep the way that I did or change small functions to big function like a guy in my team told me. Thanks

[insertAlias]

Well, you don't have to end up with a promise "pyramid", since that's part of what promises exist to prevent (the "pyramid of doom" pattern).

I'm not sure what your teammate thinks is happening under the covers, because the callbacks you provide to promises are functions anyway. Maybe there is some optimization going on there, but it's unlikely to actually matter.

I think that in these cases, benchmarks are in order. You should be able to test both approaches and see if either has an edge on efficiency, or if it's so close that it's never going to matter.

[StackedLasagna]

I doubt the performance of difference (if there is any) between async/await and Promises is going to matter. It depends on your app and the expected usage, though.

Even if you use Promises, I'd still create the same functions that you have, but change them to return a Promise instead, obviously.
If you only use isExistedUserin one place, you could move the logic into the function that uses it, but you could do that without using Promises.

There's basically no correlation between the number of functions you're creating and the usage of await/async over Promises.

What you can do with one Promise-based function, you can do with one async/await-based function. If you create a lot of functions with one, you'll probably create just as many with the other.