by 0x6438c3b1fa97ba144ea38fcbcee5f0ccf4539b1d (ph33bs)
Introduction
The Lambdas service from Catalyst was originally designed to support various independent operations required by the reference implementation client. However, as time progressed, newer and more effective endpoints with identical functions were introduced, yet the service retained all previous iterations.
This is the first of a serie of proposals that aim to enhance the resilience and efficiency of Catalyst’s Lambdas service by optimizing its endpoints and removing old implementations that didn’t take performance into consideration, making inefficient use of resources.
The main objective of this proposal is to decrease the overhead and improve the functionality of the Lambdas service by removing the now obsolete GET /lambdas/health and the redundant GET /lambdas/profile endpoints.
Proposal
GET /lambdas/health
This health endpoint was designed to handle the responsibility of reporting the status of every catalyst service, which was not an appropriate use case, thereby it will be replaced with the Realm-Description /about endpoint specified on ADR-110: Realm description.
GET /lambdas/profiles
The usage of this endpoint can be replaced by POST /lambdas/profiles which has no limitations regarding the amount of profiles you can request. From now on, the IDs to be included in the request body instead of as query strings. This change aims to address the URL length limitation issue and allow clients to request multiple profiles simultaneously, thereby enhancing the versatility and scalability of the service.
Provided that this proposal gets general acceptance level, the specified endpoints will be removed one month subsequent to its approval.
About the author
I’m Alejo Ortega, a back-end developer contributing to the Decentraland Foundation in the area of Catalyst Development. This proposal was co-authored with Matias Penthreath and Hugo Arregui.
Thanks for proposal. Would be nice to hear thoughts of Community members with technical background. Hey Folks What do you think about it ? @dax@AwedJob@HPrivakos@szjanko@MorrisMustang
Sounds good to me, no reason to keep outdated endpoints when there are replacements.
No features are being removed and it will prevent the team having to uselessly spend time on maintaining them.
It would be nice to have a set date to deprecate those endpoints so services still using them know before when to migrate.
This is a great idea. I echo everyones sentiments about reducing complexity and not having to support endpoints producing duplicate data. Also a fan of removing the limitation that was inherent of url character length.
What do you think about it ?