proxy.golang.org : github.com/ExpediaGroup/flyte-client

flyte-client is a Go library designed to make the writing of Flyte packs simple. The client handles the registration of a pack with the Flyte server, consuming and handling command actions, and gives the ability to send pack events to the Flyte server. This allows the pack writer to concentrate solely on the functionality of their pack. The structs that a pack developer interacts with can be found in flyte/pack.go. The main ones are as follows: Packs can send events to the Flyte server in 3 ways: 1. The pack can observe something happening and spontaneously send an event to the Flyte server. For example a chat-ops pack, may observe an instant message being sent and raise a "MessageSent" event to the Flyte server. It would do this by calling the `SendEvent()` function on the `Pack` interface. 2. A flow on the Flyte server creates an action for the pack to execute. The client will poll for this action and invoke the relevant `CommandHandler` that the pack has defined. This handler will return an event that the client will then send to the Flyte server. For example the same IM pack as above may have a 'sendMessage' command that would return either a 'MessageSent' or 'MessageSendFailure' event. 3. The client will produce `FATAL` events as a result of a panic happening while handling a `Command`. The panic will be intercepted by the client and it will recover. If they need to, packs can also produce `FATAL` events themselves as a result of the handling if they detect any errors using `NewFatalEvent(payload interface{})`. This is preferred over panicking in the handler. e.g. When defining the above pack, you will notice that 'EventDefs' are defined at the pack level (PackDef.EventDefs) and at the command level (PackDef.Commands.EventDef). The 'EventDefs' field on a Command is mandatory, so for the example pack above you would have to specify the eventdefs for both 'MessageSent' and 'MessageSendFailure' on the'sendMessage' Command struct. The 'EventDefs' on the PackDef are optional. Here you would specify any events that the pack observes and sends spontaneously. If the event you want to define is already defined in a command (as with 'MessageSent' above) then you are not required to add it to the separate EventDefs section - however there is no harm in doing so. To assist with monitoring, you can add health checks to your pack in the following way: Then simply go to the pack health check URL i.e. 'http://localhost:8090' and you will be presented with a JSON response: The following HTTP header response codes will be returned depending on the status of the health checks: A simple health check has been provided for you to check on the status of flyte-api: healthcheck.FlyteApiHealthCheck(c client.Client) and can be used in the following way: You will notice that a `helpURL` field is present in 3 locations - PackDef, Command, and EventDef. These correspond to the URLs visible in the JSON on the Flyte server at that level. The help URLs are all optional, though you should generally always have the pack level one. It's up to pack developers to provide which ones they think are the most useful. For a simple pack you'd probably just provide a single pack level help link. For a more complex pack you might want to deep link commands & event definitions to a specific piece of documentation. The URL should link to a page that describes what a flow writer needs to know e.g. what the pack does, the format of the JSON in the event payloads and the format of the json for command inputs. It's up to the pack dev where and how they host their help docs. The example below shows how to create a simplified "Jira Pack". The pack exposes a "createIssue" command allowing users to create tickets. If this command succeeds it returns an "IssueCreated" event, if it fails it returns a "IssueCreationError" event.

Registry - Source - Documentation - JSON - codemeta.json
purl: pkg:golang/github.com/%21expedia%21group/flyte-client
Keywords: flyte , flyte-pack , go , golang , oss-portal-listed
License: Apache-2.0
Latest release: over 3 years ago
First release: about 6 years ago
Namespace: github.com/ExpediaGroup
Dependent packages: 1
Dependent repositories: 3
Stars: 6 on GitHub
Forks: 2 on GitHub
See more repository details: repos.ecosyste.ms
Last synced: about 1 month ago

• Readme
• Versions 6
• Dependent Packages 1
• Maintainers 0
• Related Packages 1
• Sort

  • Name
  • Versions
  • Latest Release
  • Oldest Release
  • Dependent packages
  • Dependent repositories
  • Downloads
  • Maintainers
  • Most Stars
  • Least Stars