Is there any reason that the caller wouldn't know if the meeting they're holding has been created or not? I'd keep it simple by keeping them separate unless there's a compelling reason to meld them.
this post was submitted on 17 Jun 2023
6 points (100.0% liked)
Experienced Devs
125 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:
- Logo base by Delapouite under CC BY 3.0 with modifications to add a gradient
founded 1 year ago
MODERATORS
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.
Can't argue that.
The only thing I can think of is when the user edits meetings en masse -- say they're rescheduling their whole day and are simultaneously creating and updating the timing of blocks. That probably will be functionality I'll want to implement (allowing users to enter "edit mode" for their schedule).
That's a good question though, other than that case it wouldn't be relevant. Plus, I probably would implement a createOrUpdateMeetings() API rather than createOrUpdateMeeting should that occur. Since Create and Update are both relatively simple APIs to implement, I think I'll stick with those for now and possibly shift over to createOrUpdate if the need comes up. Thanks for the insight!
Edit: After thinking about it and tinkering a bit more, I ended up going with the createOrUpdateMeetings() approach. At least on the surface, it seems simpler and cleaner for my use case -- there will be times where my client will have a list of both existing and new meetings to send over. Still open to suggestions from everyone though, people have made good points.
I would have 2 functions: createMeeting and updateMeeting
No point having one function do two different things, especially if one of them isn't even hinted at by the function name
Well, it makes the client-side calls a bit simpler if you don't distinguish create and update via POST/PUT, so at the server-side you have a single POST endpoint which does the upsert, but there it would be sensible to dispatch to separate methods for insert and update each.
I'll echo everyone else so far and recommend a single purpose function for both. That said, if you do decide to go with a combined function I like to borrow the DB term and call it upsertMeeting().
view more: next ›