You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* added replace function
* added testing readme
* changed env to be more performant
* In this commit:
readme added more limitations and a few infos to types
Ability to share rust type between payloads by giving the schema the same name prop
Validation using json schemas at runtime
Env variable to turn on and off validation
Fixed streams never being generated currently
* made service_port a port
* made basic example use validation
* fixed naming being inconsistent between schema and rust types
* added comment for how to use test command
* fix wrong env names in handler
* simplified message names
* fmt
* added performance hint for validation
* brought policy into scope
---------
Co-authored-by: Jacob Große <jacobgrosse@Jacobs-Spectre.fritz.box>
Copy file name to clipboardExpand all lines: README.md
+5Lines changed: 5 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -54,11 +54,16 @@ just service-doc {project-id} # Alternatively, you can use 'cd output/{project-i
54
54
55
55
Remember to replace `{project-id}` with the name of your generated microservice (`title` field from the provided spec).
56
56
57
+
## Types
58
+
Rust types will be generated in the models folder according to the given payload json schema definitions. Names will be generated according to channels etc, if you want to share a payload type between two messages, make sure to use the same "name" property in the payload. Warning: This will not check if the types of those payloads are actually the same, so make sure to use the same schema or better even, simply a ref to the schema with the name. By default, all defined properties are required and no additional properties are allowed, if you want to use optional types, please modify the generated types after generation or use oneOf/anyOf/allOf to represent optional types.
59
+
57
60
## Limitations
58
61
59
62
- Only json payloads are currently supported for automatic deserialization
60
63
- Only one server is currently supported and only nats protocol is supported
61
64
- Only one message is currently supported per channel, payloads can be choosen freely including anyOf/oneOf/allOf
65
+
- The generated rust types are required by default, if you want to use optional types, please modify the generated types after generation or use oneOf/anyOf/allOf to represent optional types
66
+
- references in the specification are only suppported inside the same file, external references are not supported
0 commit comments