ufukty / gonfique Goto Github PK

...
Create: { Method: "GET", Path: "/post" }
Update: { Method: "PUT", Path: "/post/{id}" }
Delete: { Method: "DELETE", Path: "/post/{id}" }

type Method int

const (
  GET = Method(iota)
  POST
  PATCH
  DELETE
  PUT
)

type Endpoint struct {
  Method Method `yaml:"Method"`
  Path   string `yaml:"Path"`
}

Considerations:

• Enums can be defined with a type other than the one in YAML (eg. string <> int above)

In an example config file below

# config.yml
Github:
  Domain: github.com
  Gateways:
    Public:
      Path: /api/v1.0.0
      Services:
        Document:
          Path: document
          Endpoints:
            List: { Method: "GET", Path: "list/{root}" }
        Objectives:
          Path: tasks
          Endpoints:
            Create: { Method: "POST", Path: "task" }
        Tags:
          Path: tags
          Endpoints:
            Creation: { Method: "POST", Path: "" }
            Assign: { Method: "POST", Path: "assign" }
Gitlab:
  Domain: gitlab.com

Github.Gateways, Github.Gateways.Public.Services and Github.Gateways.Public.Services.Tags.Endpoints are all not literally but semantically lists. There could be contexts that iterating over items of those lists (whose types are hypothetically []Gateway, []Service, []Endpoint) inevitable; eg. a generic function that takes a list of Endpoints and registers into router.

Considerations:

• List items in YAML files are not required to share same schema.
• Field names are not available to iterating over, since they only exist before compilation.

This issue copied from comment on #2.

Looking specifically at the K8s manifests you posted, I'm going to use one of them to illustrate my concern:

---
apiVersion: v1
kind: Secret
metadata:
  name: my-secret
  namespace: my-namespace
type: Opaque
data:
  password: MWYyZDFlMmU2N2Rm

Not sure what gonfique would generate for this, but if I were to hand code it I would want it to generate the following:

package K8sObjects

type Kind struct{
	Name string
}

type Namespace struct{
	Name string
}

type SecretType string

const (
	OpaqueType SecretType = "Opaque"
)

type MetaData struct {
	Name string
	Namespace *Namespace
}

type Secret struct {
	ApiVersion string
	Kind       *Kind
	Metadata *MetaData
	Type SecretType
	Data *SecretData
}

type SecretData struct{
	Password string
}

Clearly, to generate that from the YAML would require a lot of out-of-band configuration.

Mapping

Here is a configuration for that which I quickly mocked up, which I am sure would need to be significantly reworked to be usable. But obviously this type of config could not be fully encoded via command line flags without being wildly unusable. And note, this example only specifies that which cannot be discerned directly from the source YAML file:

---
schemas:
    schema:
        name: Secret  
        match: 
            - .kind: Secret
        types:
            - .kind 
                - type: struct
                # Struct from string defaults to one property: `.Name`
            - .type
                - name: SecretType
                - const: {{value}Type = "{value}"  
                # `type: string` is assumed for single value properties in string format
            - .metadata 
                - name: \*MetaData
                # `type: struct` is assumed for dictionaries
            - .data 
                - name: \*SecretData
                # `type: struct` is assumed for dictionaries

You may look at this and say:

"What's the point? That requires too much configuration; I just want to point at the YAML and be done with it."

If that is your response, I would argue:

1. Generating less than well-structured types will just simplify the easy part — writing types — and make the much more complex part — using types over the lifecycle of the app — even harder.

2. I see this (type of) configuration being done once and then used many times, by many people. For example, you could write gonfique and then others could create config for specific use-cases, like Kubernetes, and then host those configs in their own repo. If that did transpire, you'd be spawning 3rd party developers for gonfique.

Also clearly, for this to be reusable you'd need more than just a .config config and a repo config; you'd also need the ability to import other config files into your repo config.

Reference from Reddit:

All the nesting in the generated output makes it really hard to read the code for when trying to work with it after generation.

More importantly it makes passing parts of the YAML to funcs as detached values types impossible without hand-editing your output and adding the other types oneself.

Why not provide an option to generate a new Go type for each dictionary? I could definitely see using it if it were to generate multiple types, but not as is. Either that, or I might have to fork it when I need it, and add that capability.

Reference from Reddit:

"YAML file can not have Go keywords as keys, eg. type: user"

Rather than disallow Go keywords, how about giving users a configuration option for an optional prefix and/or suffix for that fields that conflict?

For example:

prefix: X
suffix: _