this post was submitted on 17 Jun 2023
-2 points (33.3% liked)

Experienced Devs

3978 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 1 year ago
MODERATORS
 

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
[โ€“] TheButtonJustSpins@infosec.pub 3 points 1 year ago (1 children)

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.

[โ€“] JokersPistol@programming.dev 2 points 1 year ago* (last edited 1 year ago)

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.