CODEWITHSUNDEEP
angularapidesign-patternsarchitecturesingle-page-application
Ivy
Ivy

Reputation: 887

Best Practices for SPA calling multiple APIs?

My team is trying to figure out the best architecture for the problem below. I'd like to be able to find any existing recommendations for our situation, but it's difficult to search.

A has a table of A-specific document metadata. These records represent attachments of files to other things in A and contain the IDs of the document records in B

To list attachments for a given item, A frontend gets A document records, then uses the result of the call to A to fetch the rest of the metadata (filename, size, etc) from B

We had an idea to eliminate the second call by duplicating the data returned from an upload to B in A's metadata.

So, my questions are:

  1. Is there any reason not to duplicate the data?
  2. I've had trouble googling it so far—I feel like I'm missing jargon or some term that will get me what I need. Is there a name for this specific architecture topic that will aid me in my searches?

Thanks

Upvotes: 3

Views: 2372

Answers (2)

glitchbane
glitchbane

Reputation: 337

I am thinking of doing a similar thing: an SPA calling multiple self-owned and/or third-party apis with the potential of multiple client SPAs.

To do this, I will make a proxy API that will be responsible for passing calls to each of the other apis at the appropriate time.

(the proxy API is not just a proxy, because it may perform its own operations-- it's more like a business layer. Call it what you want.)

The client will talk only to the proxy api, and will have no knowledge of the real apis.

Each API will only be responsible for data applicable to that API, but can correspond with the proxy API to get data from other APIs as necessary.

For example: Client C needs to retrieve and/or store information from/to APIs A1, A2, and A3. We create proxy api P. C asks P for combined data from A1 and A2. P asks A1 for data then asks A2 for data. P combines the data and sends it to C. The reason P combines it and not C is that multiple clients may need the same combined data.

I would avoid duplication of data unless absolutely necessary. You can store keys in the tables or objects of other data stores, but not the data itself-- otherwise you are open to dirty data if/when things go awry with one or the other of the apis.

The proxy API can also be responsible for authorization/authentication against each API, if needed.

In this way, each client can talk to the same proxy api, and client code need not change.

Upvotes: 1

mickaelw
mickaelw

Reputation: 1513

I think we can speak of micro service.

For data duplication that's depending how you want to treat it. Your data must always be up to date?

If it's a kind of data, you can duplicate the data into A backend. E.g: A row in invoice

Otherwise, from A backend you call B backend to merge data and you send to your clients (frontend) only useful information.

Your clients must know only one endpoint.

Because, if you have 3 clients (e.g .: website, mobile app, tab app) which have the same feature. Tomorrow, B changes, you have to check your frontend code everywhere.

Whereas, if only A knows B, you change the connection into A. Generally, it's transparent for your clients

Some reads: http://microservices.io/patterns/data/event-sourcing

Upvotes: 1

Related Questions