Message

Sylk Message

In Sylk, a message resource is a container for a specific set of data that represents a single message being sent or received by a microservice. This data is defined using the Protocol Buffers language, which allows for easy serialization and deserialization of the data, as well as compatibility between different programming languages.

In Sylk CLI, you can define custom message resource types using the

# Associate a message to known package
sylk generate message foo.bar.v1.SomeMessage

#  foo . bar . v1 . SomeMessage
#  |     |     |    | 
#  |     |     |    | 
#  |     |     |    └─ The name of the message.
#  |     |     └─ The version of the package.
#  |     └─ The namespace of the package (logical grouping).
#  └─ Root namespace.

# Generate a message and interactively 
# chose a package that will hold the message
sylk generate message SomeMessage

👀 Info

sylk generate command options are listed in the CLI Commands section

A message resource consists of one or more fields, which can have various data types, such as strings, integers, booleans, or custom defined types. Each field also has a unique name and a tag number, which are used to identify the field within the message.

When a microservice sends a message, it creates an instance of the message resource and populates its fields with the relevant data. This message is then serialized into a binary format and sent over the network using the gRPC protocol.

On the receiving end, the message is deserialized back into an instance of the message resource, and the microservice can access the data in the fields to perform any necessary processing or logic based on the contents of the message.

Overall, the message resource is a central component in Sylk's communication system, allowing microservices to exchange data in a standardized and efficient manner.

Inline resources

A sylk message can contain an "Inline" resource that will be only available to the message fields. The inline resource can be one of the following:

• Message - can be recursively deep nested messages
• Enum

syntax = "proto3";

package foo.bar.v1;

// The parent message
message X {

    // an inline message inside "X"
    message Y {
        string test = 1;
    }

    // an inline enum inside "X"
    enum Z {
        UNKNOWN_Z = 0;
        Z_1 = 1;
        Z_2 = 2;
        Z_3 = 3;
    }

    // Inline resources can only be in use inside the message fields
    // Other messages will not be able to reference:
    //   - foo.bar.v1.X.Y
    //   - foo.bar.v1.X.Z
    Y inline_message = 1;
    Z inline_enum = 2;
}