0

I'm currently building the front-end of an application using AngularJS. I don't have a whole lot of knowledge about the back-end, but some of the data I'm being served by the back-end developer is becoming difficult to work with, requiring a lot of rejigging on the front-end, and I'm starting to suspect that we could be handling it better. I just wanted to get some feedback about best practices for how data should be served, particularly whether data should be extracted with id references to other data already served.

When creating an item, a few getAll methods are called to populate dropdowns or radio buttons. For example:

getAllStatus

[
   {id: 1, status: 'new'},
   {id: 2, status: 'used'},
   {id: 2, status: 'handMade'}  
]

getAllType

[
   {id: 1, type: 'flatHead', length: 'long'},
   {id: 2, type: 'machineOval', length: 'long'},
   {id: 3, type: 'machinePhillips', length: 'short'},
   {id: 4, type: 'hollowHeadSet', length: 'short'},
   {id: 5, type: 'selfTapping', length: 'medium'}  
]

After an item is created, here is an example of a packet of data I might get from the server for that given item. I guess idType and idStatus are foreign keys to the previous data sets:

{
   id: 0,
   idStatus: 2,
   label: 'sample',
   idType: 4,
   idRestriction: 3
}

The back-end developer says that because I have received all the data with the getAll methods already that I should just extract the data from the arrays already sent that I need to display to the user. While this is possible, it has become a bit of a headache to manage. For example, if I want to get the status or type from either of these arrays, I have remap each array, inject the Angular services everywhere, run filters to extract objects by id and set the data to new properties on the model. When just using the array, the index doesn't match the id, so I have to decrement the id.

From my perspective, it would be much easier if I were given an object with string values instead of ids, for example:

{
   id: 0,
   status: 'new',
   label: 'sample',
   type: 'hollow-head set',
   restriction: 'none'
}

I guess I don't really know what the best practice is here, but the amount of manipulation I have to do with the data on the front-end feels really wrong. Would really appreciate any feedback anyone might have. Thanks in advance.

  • Both approches are right. Instead of looking for arguments against the actual solution, you should ask to the developer: why? Probably there's a good reason. What's seems reasonable and easy for you, might be costly at sever side. Ideally server-side and client-side should reach an agreement. A balanced solution that makes both developments easier. On the other hand, your problems are caused by your own design, server side have nothing to do with how you map and catch the data. – Laiv Dec 22 '16 at 13:05
  • Okay, @Laiv. Thanks for the comment. Appreciate it. – hughesjmh Dec 22 '16 at 13:11
  • Btw, if you don't expect types and status to change. Have you considered the usage of Factories instead of servicies? You could add some more logic into the Factory. For instance, how to retrive the labels by IDs – Laiv Dec 22 '16 at 13:31
  • Yep. It actually is factories that I'm using rather than services, but thanks for the advice. – hughesjmh Dec 22 '16 at 13:51
0

When possible you should avoid extra database calls if you can and work with data you already have if you can trust it. In your case there are a few reasons why I would agree with you that the server should be returning all the info you need.

  1. You already have a call to the database happening, the difference between what you want and what you are getting is negligible.
  2. Persisted data on the client side shouldn't be trusted like that, if your type data is compromised by a malicious user and you combine it with a bunch of other data you expose yourself to greater risk with less effort from an attacker. If you just use that data for the drop down then there is a much smaller risk.
  3. client side JavaScript is probably the slowest place you could do these joining operations, SQL is designed to do such things extremely efficiently, other server side languages have strong type systems that simplifies such operations. You have none of this on the client side.
  • Thanks for the advice, Ryathal. As @Laiv mentioned, it's probably something I should chat to him about when he gets back. I should have mentioned that in this instance, the foreign key value is being used solely for the purpose of extracting the value, and then that value is in some cases being reasoned over, so it's important that it's the correct value. – hughesjmh Dec 22 '16 at 13:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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