1

I'm developing a JavaScript UI client and my back-end developer refuses to pass me the data in a form that I don't have to transform afterwards. So, I'm currently working on a mapper that contains a lot of knowledge that will only lead to problems later on. In addition, the objects we receive are sometimes very deep and in many cases unnecessarily so.

In my view, the resource should pass me an object that I can immediately display in the view. I understand that this has its limitations because I'm not the only one using the resource. However, I think in an ideal scenario, the server should relieve the client of as much work as possible since we know and control what machine the server will be. The client on the other side is someone else's computer and we don't know how much that machine can stem. So, I'm wondering what the best strategy in cases like that is. I'm pretty much unexperienced in this area and I would like to get some outside input that might give me a different perspective.

  • How are you negotiating API designs?
  • Is there a tendency as to how your APIs are designed i.e. how much mapping do you do in the front-end/back-end?
  • Also, if the server doesn't pass me the data in a useful manner, what's the need for a server after all? (I'm intentionally exaggerating.)
  • Are there any patterns that help me dealing with data transformations like that?
Gerome Bochmann
  • 477
  • 4
  • 5

1 Answers1

2

I would add server side code to the server hosting your website.

Have this server side code accept the client request, call the api or apis, transform and combine the models into your view model and return it to the client.

This enables you to insert your own view model, perform caching and give a single endpoint for your client, simplifying security.

Having your own view model will as you say, enable you to keep the client side code short simple. Confined to presentation logic and optimised for responsiveness.

Ewan
  • 70,664
  • 5
  • 76
  • 161