Motivation
Kunyora
was born from the need to write highly disposable restful code and the need to reduce network-response
time. For now, we have been able to achieve the disposable
need of the software, however we are currently carrying out series of research to make sure that the network-response time is greatly reduced; these we would add to the client side code as soon as we are done. please refer to the Vision section of the documentation to get a full glimpse of what is possible now and the future expectations of the library.
However, there are lots of other factors which motivated us into building the library.
Reducing thenables boilerplate
Before Kunyora and React-Kunyora, we found out that teams across the world use the axios
library in interacting with their restful backend. Doing this muggles their code with lots of then and catch
promises calls as the UI's need to be aware of the states of the request made; such as the loading and error
state. Therefore we came up with a simple approach which wraps the axios
library and reduces data muggling. The best part is that you hardly need to manage the states of your application, instead you handle feedback especially when using a client based library like reactJs
The Need to Compose UI's with data
When building applications that do not use any view based library, kunyora
makes it very easy to handle the change in state of your application from a single place. This can be carried out using the thenables
and catchables
method exposed by the client
instance created by the library. Please refer to the Kunyora docs for more details. However, view based library integrations make it very easy to compose UI's with data. Please check the react-kunyora docs for more details.
Seperation of concerns
Concerns can now be seperated. Now, you do not need to think about managing the different states of your application. kunyora
and its client based integration provides you with ways to manage the state of your request
globally using a store. This can be done by supplying an initial config of nouns
and leaving the library to handle the rest under the hood for you.
The need for a faster Web.
Even if this has not been added yet into the library, it acts as one of the major motivation for building the library. kunyoraClient
would sometime in the future act as a decoder for response generated by the server which has already been compressed/encoded by the future kunyora-server
library. Visit the Vision section for a more detailed explanation on this.