0
\$\begingroup\$

Background

I am writing a Node app that queries a third-party Web API.

The API returns JSON data in various formats, each endpoint in a different format. My app later processes this data.

I have decided to create a separate class representing each endpoint's response data, and convert the JSON received from the server into an instance of the class, rather than keeping it as a plain old object.

Goal

My goal is to increase visibility of what fields are available inside that JSON from server, and simplify coding by using auto-completion that my IDE (VS2017) will now provide.

However, the code looks a bit redundant - I am basically copying all properties from one object into another.

Question

I want to know your thoughts whether this approach makes sense, is an overkill or if there's a better way to do it.

Code

Here's some basic code how I query the server:

Api.prototype.publishApp = async function (appId, versionId) {
  let url = config.luis.paths.publishApp.replace('{appId}', appId);
  let serverResponse = await queryEndpoint(this.key, url, HttpMethod.POST, HttpStatus.CREATED);
  return new AppPublishResponse(serverResponse); // convert object to class instance
};

And that's the class - I create one class for each endpoint:

/**
 * Represents a response from LUIS when publishing an app
 */
class AppPublishResponse {
  constructor(serverResponse) {
    this.versionId = serverResponse.versionId;
    this.isStaging = serverResponse.isStaging;
    this.endpointUrl = serverResponse.endpointUrl;
    this.region = serverResponse.region;
    this.assignedEndpointKey = serverResponse.assignedEndpointKey;
    this.publishedDateTime = serverResponse.publishedDateTime;
  }
}

Just a note, the queryEndpoint() function above makes sure that the server response code matches the expected one (e.g. 201 Created), so I can be sure that the data passed to the constructor of AppPublishResponse is always a valid server response.

\$\endgroup\$
1
  • \$\begingroup\$ I'm pretty sure VS2017 will use JSDoc annotations - haven't tested it. Would be a much simpler solution to this problem. \$\endgroup\$
    – Gerrit0
    Sep 28 '17 at 4:06
0
\$\begingroup\$

Hard coding outside data source should be avoided.

Hard coding outside data sources will present an ongoing workload. This will be compounded by the fact there is no validation of data.

At anytime the data source may change, add, or remove properties. You will not know about the change (if you don't personally follow the source doc feed) until it fails or a customer/consumer reports the problem, or worse just stops using it.

Testing for a valid response will not protect against modified data.

Even if you validate the data it will just improve response time for the fix / update but not the underlying problem.

The cost.

Every change will require an update, test, documentation, deploy, monitor, release, and pray cycle for the life of the service. As a business I would have to pass this cost/ risk on to the client or revenue source, and having a programmer on call is very expensive. In other words this type of design can kill a service.

For the sake of auto complete it is not worth it.

You are best of generating something that Vs2017 can read (I don't use it so you will have to look in the docs) and hard coding as little as possible that is outside your direct control.

\$\endgroup\$

Your Answer

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