CODEWITHSUNDEEP
javascriptnode.jsmongodbmongoose
Adrian A
Adrian A

Reputation: 452

Insert documents in different collections by calling one API

Im doing a project where i call one api, this given API service will handle all the given data and split it to different collections.

Given example

service.js

async function create(params, origin) {
  const { param1 , param2 , param3 } = params
   
  const collection1 = new db.Collection1(param1)

  await collection1.save()


  const collection2 = new db.Collection2(param2)

  await collection2.save()


  const collection3 = new db.Collection3(param3)

  await collection3.save()
}

My questions are:

  1. What is the best practice? Should I create a general model schema that groups all the collections with the parameters, "param1,param2,param3", and insert it in the collection then call another function that splits all the values into Collection1,Collection2....

  2. How can i handle if one collection insert throws an error, to delete all the previously inserted collections ? For example the values of param2 is not valid, but param1 and param3 are, how can i handle to delete the collection 1 and 3 and throw an error ? Whats the best way to achieve this?

Generally all the above examples are simplified, we are talking about at least more than 10 collections and more than 15 parameters.

Upvotes: 0

Views: 213

Answers (1)

Alexandru Calinica
Alexandru Calinica

Reputation: 66

Basically you are talking about having multiple route handlers for a single path.

Generally you should handle server-side validation & sanitation on the input data before inserting into the db and throw errors right away if rules don't match, so having to delete previous 2 collection inserts in case the 3rd one fails is not needed anymore.

Check out express-validator middleware for this aspect.

Ideally you should have one route handler per path for several reasons but I think the most common one is ease of maintenance and debugging(conceptually like separation of concerns). It's easier to execute a sequence of requests to different paths and eventually await the response from the first request to be used in the next request and so on(if that's the case). In my opinion you're just adding a layer of complexity not needed.

It might work if you develop alone as a full-stack, but if you have a team where you do the back-end and somebody else does the requests from the front-end and he encounters a problem it'll be much harder for him to tell you which path => handler failed, because you're basically hiding multiple handlers into a single one path => [handler1, halder2, handler3]. If you think about it, this behaviour is causing your second question.

Another thing is, what do you do if somebody needs to operate just a single insert from that array of inserts you're trying to do? You'll probably end up creating separate paths/routes meaning you are copying existing code.

I think it's better for chaining/sequencing different request from the front-end. It's much better and elegant, follows DRY, validation and sanitation is indeed easier to code and it gives the consumer of your api freedom of composition.

Upvotes: 1

Related Questions