this post was submitted on 17 Jun 2023
1 points (54.5% liked)

Experienced Devs

3983 readers
1 users here now

A community for discussion amongst professional software developers.

Posts should be relevant to those well into their careers.

For those looking to break into the industry, are hustling for their first job, or have just started their career and are looking for advice, check out:

founded 2 years ago
MODERATORS
snowe
jmk1ng
drewsiferr
1
createOrUpdateMeeting() vs createMeeting(). Which one do you choose and why? (self.experienced_devs)
submitted 1 year ago* (last edited 1 year ago) by JokersPistol to c/experienced_devs
9 comments fedilink hide all child comments
 

Which one is easier to develop and work with (which saves the most time)? Which one would you go for? The name of the API represents its true purpose in this case by the way, createOrUpdate creates or updates the passed in meeting and create just creates the meeting. I will be the only one working on this project for now, although obviously, I would like others to work on it with me eventually.

you are viewing a single comment's thread
view the rest of the comments
[โ€“] [email protected] 4 points 1 year ago (1 children)

Well, I can think of two reasons immediately. The first is in hermetic testing environments, where you may have two tests where you'd like to see the same entity. You can't always know the order in which tests execute. That means that either seeding operations should be idempotent, or you'd have to handle setup outside of the individual tests. (Which makes the tests, overall, harder to read.)

Another reason could be for resiliency. You may add a retry mechanism into your code in the frontend, to increase resiliency. If a request returns a 500, you don't know if the entity is created. (The server error could occur in post-processing.) You either have to rely on the creation to be idempotent, or you have to make an additional round-trip. Using a create-or-update mechanism reduces latency and simplifies error-handling code.

[โ€“] [email protected] 1 points 1 year ago

Can't argue that.