0

I have got an argument with my colleagues about this. IMO It's common practice that you don't need to check if an id exists or not before rendering it.

So here's an example. This is what my colleagues implicitly saying its proper to do.

let hotels;
getHotel().then(res=>{
    hotels = res.hotels.filter(hotel=> hotel.id)
})

Then you render the "hotels" in the view .

One of my colleague's arguments is:

hotels = hotels.select { |h| h.id }

This is selecting for any hotels that have a hotel ID. This isn’t stupid if you’re expecting there to be no ID in some cases. (He's referring to Cassandra where a key primary can have no value)

My argument is frontend doesn't care which database backend is using. It should be implemented without knowing it as best practice by assuming id is primary and should always expect to have value.

4
  • please don't cross-post: stackoverflow.com/questions/59657100/… "Cross-posting is frowned upon as it leads to fragmented answers splattered all over the network..."
    – gnat
    Commented Jan 9, 2020 at 8:18
  • @gnat Deleted I was recommended that I should post it here instead. Commented Jan 9, 2020 at 8:29
  • In Cassandra a primary key with no value is NULL right? I would consider NULL to be a value that represents "no value". How are these Ids used on the front end? Commented Jan 9, 2020 at 13:57
  • It'd be worth your while to consider how likely it is that you'll be connecting to other database backends besides Cassandra. If it's unlikely to happen then why bother to code for something that's unlikely to happen? If it is likely to happen then I'd say yes, your assertion is reasonable. The point is, it's poor practice to add code to support future cases which may never arise in actual practice. It just makes things harder to understand for very little gain. Commented Jan 9, 2020 at 16:22

2 Answers 2

2

My argument is frontend doesn't care which database backend is using.

Sorry, but that is actually an argument for checking of the existence of IDs. The database backend is an abstraction which tends to be leaky - it does not matter how much effort you invest to make your frontend DB agnostic, there is always something which behaves differently when you change the backend (at least the performance).

If in the described case two different backends are possible, and in one backend ids are mandatory, whilst this is not the case in the other, you obviously have to take measures in the frontend to deal with both cases. That does not mean this has to be done at each and every place where the IDs are used. There could also be an intermediate layer which makes sure the records have an ID at the time they are rendered.

So this boils down to the question "how much database independency do you require really"? If you know for sure records come from a DB which assures you the existence of the IDs, then you can omit the checks. This is a perfectly valid approach - writing a 100% database agnostic frontend is often not economic. Neverthless making code to some degree db agnostic is fine.

2

In general, you are correct. The back end should be abstracting the detail of the database away. We've switched databases twice without the front end even knowing. If you need a list of hotels with ids, the back end should provide a way to query only hotels with ids, regardless of what database is in use. Expecting the front end to filter a table is error prone and wasteful of bandwidth and processing power. The front end doesn't have access to the data structures that make filtering a table efficient.

The behavior of your colleagues strikes me as defensive behavior after getting burned. It would be very unusual for a well-designed Cassandra query to return some rows with ids and some without, but Cassandra data modeling is unintuitive if you are accustomed to relational databases. I'm guessing after a switch there were some mistakes migrating data in the back end that the front end had to compensate for, and they overgeneralized about the problem. Every shop has a few of their own quirky superstitions like that.

Mostly in those cases you have to go along until you can prove somehow that the superstition is unfounded. I would probably log an error if I received any hotels without ids, and work with the back end to prevent that from happening, then show my colleagues that it got fixed and they can stop being so defensive.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.