Choose technology and architecture

[ldmi3i]

I propose to discuss here the choice of user interface technology, as well as in what format, in principle, to design the UI. (for example, maybe it makes sense to separate the part with client side calls into a separate service?)

Initially I supposed to use some JS framework (Angular, Next JS to provide SSR for the SEO). But may be there are better options.
And perhaps something separate like webview may be used for the API definition client .

[pallasite99]

I’m also not that experienced with prod level UI, but I would suggest to have a middleware layer apart from client and server - which can do some level of caching to return the most frequent results.

The reason why I mention this is to not keep querying the server with every new request

[pallasite99]

@ldmi3i Something like this maybe was what I had in mind

[ldmi3i]

Yes, I agree with you.
Requesting server with each request is not good - it may create load without purpose.
Initially I was thinking about uploading full API dentition on client side when user selects some specific API from search results (and it may run as some embedded application - it's why I have some thoughts about webview, but I don't have any experience with it). But it may be a lot of information (or may be not, I'm not sure). And caching looks like good solution here.
But I'm not sure we need additional layer for that.
Maybe we can just add Redis instance to API Gateway and cache required requests directly?

And here we also need to provide cache clearing because API definitions might be updated. And for example we may send notification to drop cache by some API definition from storage and update service with queue for example. But with concept of keeping caching middleware outside of microservices system we may have problems with stale data and cache control in general.(IMO)

[pallasite99]

https://github.com/ranjanrak/dead-letter-queue

By redis do you mean something like this?

[ldmi3i]

No, by Redis I meant just Redis - just shared memory. In this case we don't need queue. I meant map ( HASH redis structure) to cache args as key and responses as values. And on retrieving requests Gateway may check response in the map, response immediately if exists, make request to database if not.

[ldmi3i]

Redis required only in case of replication of gateway (We may cache inside gateway at the beginning, I was thinking about Redis just for scaling possibility)

[ldmi3i]

@pallasite99 I think I have some misunderstanding of your idea. Could you explain it again.
Maybe it will be simpler to understand by the example request flow
For example

• User opens one of the open API requests
• Client (browser) requests server for the details
• Middleware retrieves request first and cache some request paths.
• If request already cached responding immediately If not - pass request to Gateway
  (how I got the idea)

But in this way cache "need to know" about internals behind gateway (when some API definitions updated by internal update process - for instance was rechecked by schedule) to drop cache on updates.
Do you mean using of the queue to send requests from Gateway to middleware?

[pallasite99]

Yes, I mean the same concept as yours here @ldmi3i

We were planning to do this in our product earlier but unfortunately the components were heavy although running on K8s so the architecture didn’t allow that.

The cache doesn’t need to know about internals, just sends the REQ to server if it cannot serve the request (not present in cache)

[haani-niyaz]

To solve the caching issue, we could use a delete-on-update strategy to update the cache when the datastore is updated. If the cache update fails, it could drop it in a queue for retries.

[ldmi3i]

Yes, caching issue can be solved in this way, but I have some misunderstanding how it can be done outside of Gateway. Requests pass from client as text with path and data. Thus we may cache all request with params to response. To delete such a cache on update, for example by ID of updated API definition - the middleware needs to know how ID relates to request and to witch exactly request it relates. So this middleware needs to know about methods structure. And in such way this middleware becomes something like API Gateway.
This is what I can't understand. For me it looks like caching fits to API gateway component, but not to outside of it.

[haani-niyaz]

Yes, caching issue can be solved in this way, but I have some misunderstanding how it can be done outside of Gateway. Requests pass from client as text with path and data. Thus we may cache all request with params to response. To delete such a cache on update, for example by ID of updated API definition - the middleware needs to know how ID relates to request and to witch exactly request it relates. So this middleware needs to know about methods structure. And in such way this middleware becomes something like API Gateway. This is what I can't understand. For me it looks like caching fits to API gateway component, but not to outside of it.

The part I failed to mention was that the service that owns the datastore also owns the modifications to the cache. This creates a service boundary, in that the service owner is also responsible for the cache. The middleware is just a consumer.

[ldmi3i]

Yes, I understand that. The owner of the data is the 'storage and update service', it can, for example, notify the Gateway.

Okay, for instance we have methods GET /api/v1/spec/method/{id} , also method GET /api/v1/spec/{id} and probably other related methods.
If the API specification with id 1 is updated, we will need to clear several caches.
We will need to drop cache for the GET /api/v1/spec/short/1 . We will also need to drop caches for it nested entities
GET /api/v1/spec/method/{from 1 to 100 for example} .
So the 'storage and update service' knows the cleared ids and can notify API Gateway. If middleware will be outside API Gateway it will need to identify the endpoint paths by those ids and send them to middleware to clear cache (because middleware knows just path requested). And we'll have queue with paths to clear. (and it would be good if only with paths)
Maybe it is easier to cache inside 'storage and update service' which has access to db? (It much more easier to do it here - on update we have all data for dropping cache) Or in the API gateway service?

With such external middleware we'll have at least 1 additional notification chains and I don't see any benefit.
API Gateway is middleware by itself. It only function to pass requests to required service.

[haani-niyaz]

@ldmi3i, I think we're on the same page.

Maybe it is easier to cache inside 'storage and update service' which has access to db?

This is what I was trying to say. The API Gateway/Middleware doesn't need to be notified to keep the cache updated. The "storage and update service" as you put it will keep the db and cache updated. The API Gatway/Middleware just consumes from it.

[ldmi3i]

Ah, yes, I don't understand, sorry. I completely agree.