-1

I'm building a web app that will integrate with the Etsy REST API and persist information in a database for things like order information, listings, etc. Essentially a panel to manage Etsy orders and products. What I am currently stuck on is how I should architect the backend API.

Currently, my backend is structured into two different API parts:

  • Endpoints which perform CRUD operations on the database (that the frontend uses to display the data)
  • Endpoints which interact with the Etsy API and persist any updates to the database (e.g to fetch any new orders, to mark orders as shipped, to apply tracking information, etc)

However, from what I understand this is not the correct way to architect the backend. The way I see it is the frontend should not need to know about the third party API that is being interacted with behind the scenes, instead the backend should be making those calls and then persisting any data all at once. I just don't understand how the logic is supposed to be wrapped together in an efficient way; if I coupled the logic to fetch new orders from the Etsy API and then persist any new ones in the database under one single endpoint, the frontend is going to be making a call to Etsy every time it wants to just fetch the orders from the database (maybe there aren't any new orders) and that seems wasteful.

I assume this is a common API design scenario yet I'm struggling to find anything related to this so apologies if this is a duplicate or stupid question, I'd just be really grateful if someone could point me in the right direction. I'm using Spring Boot for the backend.

1
  • 1
    Assuming you can find a way around any terchnical problems, what is the ideal way you would like to update your app with new items from Etsy? Oct 22 at 8:26

1 Answer 1

0

I would argue your intition that the Frontend should not directly interface with an external business is correct. As always, there's nuances, but in this case there's multiple reasons why you want to do this, here's a few of them.

  1. Niceness: If your service scales, you need to be able to regulate how much you hit third party endpoints, as otherwise they might block your service entirely. This is really difficult to do client-side, and malicious actors could certainly prove a problem
  2. Security: Depending on the API you might require secure API token (I assume Etsys API does for your use case), and providing these to the frontend might be an vector of attack.
  3. Data Control: You have the chance to manipulate data in the backend to fit your use case better before passing them onto the client.
  4. Caching

To the actual question.

What I understand is, that you are worried about putting the third part endpoints calls into your backend, because then you need to make that call every time someone calls your backend endpoint.

This relates to niceness - it's indeed troublesome, it introduces latency, and is probably often just entirely redundant.

Depending on your requirements, you have a few choices.

  1. You just query the data every single time. Simplest solution, but does increase roundtrip latency and is not very nice. Depending on Use case and scale, this can be absolutely acceptable. You'll never have stale data, this way.

  2. You can query the data regularly in the background - using an Task Scheduler for example (Since you're working with Spring, check the @scheduled annotation). You store this data into your own database, or just store it in an cache. Your own business logic will then simply use that stored data, instead of making their own API call.

  3. You query the data on demand, but keep it around for a bit until it's stale. This does mean you put the API call into your business logic, but you also cache it afterwards for a specified amount of time. The system will not re-query the endpoint while it has data in the cache. This increases roundtrip time for the first time every n minutes, where n is the time until you consider an entry to be stale, but is very nice on the third party service.

There's probably many more choices, but those would require more intricate details. Either ways, unless etsy offers webhooks for the APIs you need, you're gonna have to do a tradeoff between how recent the data should be and how nice you want to be.

For the last two solutions, you will have to deal with cache expiration. When you do actions that mutate the data on the etsy backend, you'll have to re-fetch all necessary information. Something to keep in mind.

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.