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.