lerenn / asyncapi-codegen Goto Github PK

Title is explicit.

Should we add validation for JSON schema core values?

https://json-schema.org/draft/2020-12/json-schema-validation

could be middleware which is automatically added or a defaultValidation middleware which is up to the client to add?

First things first: Thanks for this awesome package! 💙
Are there any plans to support NATS JetStream?

what the Readme says and what the makefiles do is a bit confusing.

Hello world generates 2 apps.

But the root README.md only shows generating one.

Perhaps just alter the hello world Makefile to also do the code gen. The sub Makefile does the docker compose running as it does now.

As there is no check, when there is a problem with the AsyncAPI specification, then it is not always detected.
Adding a checking before should resolve this problem.

For now, every listener on the NATS implementation will receive every message. In case of duplicated services, it would be necessary for just one of them to process a message, thus using the queue groups functionnality.

It would be nice to have to be able to perform compile-time/initialization time checks in the application when implementing brokers that expect some known channels for configuration and would error out on an unknown channel, becase currently broker accepts channel as a simple stream

type BrokerController interface {
	// Publish a message to the broker
	Publish(ctx context.Context, channel string, mw BrokerMessage) error

When requesting something, expecting a response, the client has to filter by correlation-id.
This should be automatically generated.

This is just. suggestion that you may find useful ?

https://github.com/samber/slog-nats is a golang slog adapter to log into NATS

Been using it as it makes it easy as DEV and OPS time to see what's going on for a local or remote system.

Sometimes, we have a reference to a schema which is a string or an array of string (or anything else), and it would be great to be able to convert them easily.

Hi,

Thanks for this project!

I wanted to give it a try but it doesn't seem to support AsyncAPI v3.

$ asyncapi-codegen -i ./asyncapi-v3.yaml -p asyncapi -o ./asyncapi.gen.go
 --- Anomalies detected in specification ---
version "3.0.0" is not supported

Any plan to support it?

Thanks!

System Info

Arch Linux
go version go1.20.6 linux/amd64
asyncapi-codegen version v0.13.1

Steps to reproduce

1. Get this AsyncAPI spec https://github.com/derberg/shrekapp-asyncapi-designed/blob/36d42d6c08c0feca49b19fc3d02b2b20bf7f96f1/asyncapi.yaml.
2. Convert it to 2.6.0 with AsyncAPI studio.
3. Run asyncapi-codegen on it.
4. ClientSubscriber contains Chat and TravelStatus methods in api.gen.go.
5. Now, modify the subscribe operation under /travel/status channel to publish.
6. Then the ClientSubscriber is completely missing from the generated file.

Expected result

I expected to see the ClientSubscriber contain only Chat in the end.

Hi.

Thanks for a great package! I was wondering if it is possible to specify a different case for the json struct tags in the generated models? I.e. have camelCase instead?

So things that should be in initialization are added as method, which is not ideal.

As far as I know, *.go source files are not meant to be executed directly. Why is the generated api.gen.go files set to 0755 permission?

Split application/client generation for publish/subscription in order to match controller/adapter in hexagonal architecture.

For now, when generating a spec with a multi-line description, there is an error as the generated description is commented only on the first line.

This following description:

      description: |
        Status event is happening when there is no more expected event.
        An 'advance' message can be sent after this one.

Will generate this code:

// Description: Status event is happening when there is no more expected event.
An 'advance' message can be sent after this one.

And should generated this instead:

// Description: Status event is happening when there is no more expected event.
// An 'advance' message can be sent after this one.

Do you have a game plan of how your going to support Schema Evolution ?

We have things in 2 places ..
There is a schema description in the yaml and the data living inside nats that conforms to a version of the types described by the yaml schema.

this is not at all unique to your project but in fact an issue with nats itself in my opinion.

The problem is reduced if protobufs are used instead of json . It async-api wants to use json . So then a work around is if we can store the data inside nats as protobuf and convert it to json on the way in and out …
So then you won’t need to go back and adjust the pending data inside nats.

just an idea..

anyways it’s a cool project @lerenn

For now, when a default value is specified in the specification, it is not used.

The entity having a default value should be optionally settable, with the default value by default.

Add pertinent linters from here: https://golangci-lint.run/usage/linters/

Was playing around and we could gen a lot more here if we wanted.

CTL is a pretty obvious one I think

For a GUI, we could use HTMX, which is nicely designed to work with async using SSE or Web Sockets which NATS naturally supports already.

Here is a simple golang htmx generator.
https://github.com/gowebly/gowebly is a generator that uses htmx and golang.

• backend: https://github.com/gowebly/gowebly/tree/main/internal/attachments/templates/backend/default

• frontend: https://github.com/gowebly/gowebly/tree/main/internal/attachments/templates/frontend

Hello, thanks for making this useful tool!

I would like to suggest adding support for an extension to allow specifying Go types, like x-go-type from oapi-codegen.
Ref oapi-codegen/oapi-codegen#212.

If you think this is feasible, I can try drafting up a PR later.

In AsyncAPI documentation, both part of the interaction are called "App" and "User(s)" (where the server is actually the event broker). Here it is "App" and "Client", so "Client" should be changed to "User".

For now, when the business logic that receives a message fails, then there is no way to tell the broker.

We should be able to do this following this schema:

flowchart TB

Emitter-->Broker;
Broker-->Reception;
Reception-->BusinessLogic;
BusinessLogic-->Success;
Success--ACK-->Broker;
BusinessLogic-->Failure
Failure--NACK with or without delay-->Broker;

I was wondering if async api Standard supports json Schema ?

Cause then we can use that to describe the types but also to do validation.

I am not that familiar with async-api btw.

nats uses json Schema Inside to validations its own types btw. It’s inside the packages called jsm but is not really designed for external access.

You know there is nothing preventing the json Schema or even the async-api being deployed inside nats kv. Then nats Server has the Schema inside itself to do the validations . Just an interesting way to have it all inside nats like a database has the data and schema inside itself.

For now, the loggers uses additional information from context, but doing a custom logger makes it hard to get those info as each one should be unwrapped from the context.

So we should make it explicitly passed by argument in the generated code and remove the context embedding in loggers (not in the generated code though).

For now, the headers are not generated in brokers messages.

Logging should be available with ECS capabilities (Json with with specific fields).

When there is enumerations, there should be a validation on send only.

NATS Jetstream should be added to list of tested brokers to assure non-regression.