Go libraries

v0-7
proposal
#1

Hey guys,

I recently deprecated both go-application and go-service.

go-application

This lib has been deprecated because (like the js library) we don’t want to support the when/then logic.
It’s concept and implementation were not perfect and require a lot of time to make it good.
This logic will be implemented in the future with the workflow system and not as go or js libraries.

The generated gRPC go protofile are well done and pretty easy to use for any go developer. So we don’t need to provide wrapper on top of it (as opposed as the js lib).

Developer should now import directly the coreapi package.

go-service

This lib has also been deprecated because it is not using the serviceapi package from core because of vendor issue if I remember well.
The go-service lib is useful and make service development a lot faster.
I suggest to keep it but to move it in core repository so it’s easy to maintain and will be easily reusable in system services as well.

I suggest to move this lib in github.com/mesg-foundation/core/client/service.

@krhubert @ilgooz @Anthony what do you think / do you agree?

Milestone v0.8
Milestone v0.7
#2

  • Application can be archived in favor of workflows. I don’t think we’ll ever need to use an application client when workflows gets really mature.

  • Keeping high level apis for service client is good. I don’t mind if we move it to Core or keep separated, as long as it’s importable as standalone. With go mod, maybe we can solve the issue with vendors as well if we chose to keep this pkg in a separated repo like now.

#3

I’m ok but we have to remove vendor direcotry

#4

I would love to get ride of the vendor folder!

#5

Done in https://github.com/mesg-foundation/core/pull/704