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
this post was submitted on 17 Jun 2023
-3 points (20.0% liked)
Experienced Devs
3950 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
Many databases or database clients have an "upsert" operation which is exactly this. Create or update this entity. If the DB supports it you can save an explicit lookup giving minor performance and code cleanliness improvements in application but might shift that performance cost to the DB (had to rollback a prod change not too long ago because someone switched to a PG upsert and it caused average CPU to rise, haven't gotten a chance to investigate why yet, something about indexes probably).
Anyway, I tend to start with just explicit create and update methods and add an "upsert" abstraction if I find myself sprinkling lots of checks around making code messy. So I would go for "createOrUpdateFoo" in that case.
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.
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.
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.
Even if I had a createOrUpdate function I would still have an explicit create function so that I can have a permission model that allows for creating but not updating. For meetings maybe it doesn't matter, but I worked in a financial setting where a very unfortunate design decision was made early on in the development of a ledger where it was crucial that transactions couldn't be updated, but the database was designed in such a way that there wasn't a way to give the application permission to create new transactions without also allowing it to update existing ones. Required quite a bit of work to build around this limitation and have a way to prove that a series of transactions hadn't been altered.