-2

We sell a fleet management solution: it includes a mobile application, a web application and a set of APIs.

Technically the APIs and the web application are developed in C # .net (asp.net mvc and asp.net webapi). We are using as source control.

Our standard solution is implemented for a certain number of customers. The problem we are facing now is that we have had several large account customers lately who wish to have product customizations for their own case. For example: in the user account management module, one of our large customers requests the possibility of linking 3 additional data (employee's internal identifier number, warehouse code and affiliation number): this data n have nothing to do in our standard APIs.

The question is therefore how to make changes in our base code, and develop our APIs as a product while meeting the requirements of our client. We indeed want to avoid having duplicate code that is too specific and difficult to maintain while trying to have a stable common base.

Some of us say that we must plan for this customer to create a new git repository, then push our product branch, and finally make the specific changes requested by the customer. Some others want's to modify for each specification ou product base code if needed in order to place an extension point in order to let the possibility for a customer to extend it (for example add the 3 new specifics fields int the api and the underlying database table for the user account)

2 Answers 2

1

There is no silver bullet in this scenario, but you have to evaluate a solution for each customization aspect that you have to face in time, trying to keep separate the core api from customized services

If customers just need to extend the information associated to some resource (company, user, asset) the most flexible solution is the introduction of properties as key/value pairs directly provided by customer. Properties could have a customer defined schema, but this makes the user/developer experience more complicated because it have to declare keys and types ahead of time

example:

PUT /users/:userId/props/mykey
{
  type: "string",
  value: "foo"
}

PATCH /users/:userId/props/mykey
{
  value: "bar" (if it was a number, i'd have a 400 error)
}

GET /users/:userId/props
{
  mykey: { 
    value:"bar",
    type: "string"
  },
  mynumber: {
    value: 3,
    type: number
  }
}

When customizations impact on domain model, it would be reasonable to develop a dedicated backend that acts as proxy to core APIs, there would be an endpoint like api.mycompany.com/rich-customer-api/v1... or a backend-for-frontend if you are providing access through mobile/web app

Finally, if customizations have low impact on platform evolution or appear reasonable and useful for other customers, why not consider them as new features for the core apis?

0

I think it's good that you are seeing the requirement because there will be a large, profitable customer base who will only buy your product if it can be reasonably integrated with the dozens if not hundreds of systems they already operate. Don't hack this though, think about sustainable ways to store user data with your data.

A simple solution is to have a user data field with your business objects. Typically this would be a text field and the contents are of no interest to your own application. Your only job is to accept it's contents on write and display it on read.

Most customers should be able to live with one user data field. For example, they could store their user ID in the field, and then look up the rest of the information in their own system. Point is, don't take their requirement at face value, see what the minimum implementation would be that would still meet their goals.

If the customer needs multiple values, they can stuff these in a JSON object and then store the JSON (XML, AVRO ...) object in the user data field field.

Enterprise grade products often have an extensible schema where the customer can in fact add their own typed data.

I recommend against customer specific fields or (gasp) branches.

1
  • Interesting I was also thinking about storing a blob field in database filled with custom properties in json format...
    – Dypso
    Commented Jan 21, 2020 at 22:14

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.