Closed ilgooz closed 6 years ago
If the application lib's API is flexible enough to not having to use the low level API, then we can stop exporting it. The actual mesg-js is too limited. For example, you cannot execute a task if you don't listen for an event. I would like to force developers to respect the way MESG should be used (by listening for events and executing tasks) but I think the lib should be flexible for a dev to start experimenting without having to create services in the first place. After their experimentation are finish, then they should create services. @antho1404 what are you thoughts?
I really don't think we should add a way to execute a task directly without linking an event.
I really think we should keep the library to the minimum functionalities and focus on these ones and then later on maybe improve if needed.
We shouldn't fix things in the libraries but make sure that the API is good and work on this one instead. For the part to log we can have either a service Log
or include this feature directly in the core
For the part to trigger an event to see if the execute works well we can have the same either a service that just emits an event on start or a special feature on the core like a core_test_event but we definitely don't need to overcharge the libraries with that
for the low level apis it really depend what we want to do with this lib, if it's a lib to build applications I don't think we need to wrap other apis than the listen event/result and execute task. Others should not be needed.
If we want this library to be used as part of a build process or some stuff like that if might be helpful to at least expose them but as long as this is the "advanced" mode I think we don't need to wrap them and we can let the low level api and I'm not even sure it's something we need to do if we just want this library to be use to create applications
antho1404: If we want this library to be used as part of a build process or some stuff like that if might be helpful to at least expose them but as long as this is the "advanced" mode I think we don't need to wrap them and we can let the low level api and I'm not even sure it's something we need to do if we just want this library to be use to create applications
Let's just return the gRPC Client to allow devs to use the low level API. They will need to refer to the gRPC API to know how to use it.
I think we should simply wrap needed gRPC methods with high level package methods. Users should never be aware of the underlying network protocols we're using internally because it's not relevant with what they are building also, they shouldn't use and rely on these internal APIs because they can be changed in future(when we update our proto files).
I publish the API on the wiki: https://github.com/mesg-foundation/core/wiki/Public-API-of-Application-Libraries Any feedbacks?
I reviewed the latest version of the Application API and very happy about it. It looks very convenient.
I would add the definition first in the wiki and then the example but other than this it's perfect 👍
I like to show how it should look like first. I think it will give a lot of knowledge to the developer. And then he can see the definition he should respect.
It sounds a bit weird for me to have an example and then the explanation, for me most of documentations always explain the details and then show some example of implementation but it's a detail i will be ok with something like that also
Some of this discussed under https://github.com/mesg-foundation/core/issues/278.
Discussions