Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add NatsClient to DI #689

Merged
merged 20 commits into from
Jan 27, 2025
Merged

Add NatsClient to DI #689

merged 20 commits into from
Jan 27, 2025

Conversation

mtmk
Copy link
Collaborator

@mtmk mtmk commented Dec 4, 2024

This change modifies the default serializer and pending policy, hence it is technically a breaking change. To preserve the original behavior applications can add these settings:

services.AddNatsClient(nats =>
{
    // DropNewest was the default, now it's set to Wait. So if you want to keep
    // the behavior before this PR add the following line:
    nats.WithSubPendingChannelFullMode(BoundedChannelFullMode.DropNewest);

    // If you were not using custom serializer which doesn't derialize ad hoc JSON
    // objects make sure to add the following to keep to original serializer settings:
    nats.WithSerializerRegistry(NatsDefaultSerializerRegistry.Default);
});

resolves #687

This change modifies the default serializer and pending policy, hence it is technically a breaking change.
@mtmk mtmk linked an issue Dec 4, 2024 that may be closed by this pull request
@mtmk mtmk requested review from rickdotnet and scottf December 5, 2024 18:39
@mtmk mtmk self-assigned this Dec 7, 2024
@mtmk mtmk added the breaking label Dec 7, 2024
@rickdotnet
Copy link
Collaborator

rickdotnet commented Dec 11, 2024

These changes look good to me.

Does it make sense to keep AddJsonSerialization(...) around anymore? Seems confusing and since it now defaults to JSON, I'm not sure that it's needed. There is documentation for NatsJsonContextSerializerRegistry, could expand on that, if necessary. That combined with WithSerializerRegistry() should be the same functionality. If you wanted to keep the method, I'd still suggest renaming it to WithJsonSerializerContext(params JsonSerializerContext[]) and track it in a similar way and take out the chained options.

@mtmk
Copy link
Collaborator Author

mtmk commented Dec 11, 2024

These changes look good to me.

Does it make sense to keep AddJsonSerialization(...) around anymore? Seems confusing and since it now defaults to JSON, I'm not sure that it's needed. There is documentation for NatsJsonContextSerializerRegistry, could expand on that, if necessary. That combined with WithSerializerRegistry() should be the same functionality. If you wanted to keep the method, I'd still suggest renaming it to WithJsonSerializerContext(params JsonSerializerContext[]) and track it in a similar way and take out the chained options.

@rickdotnet good point. I know I marked this as breaking already (actually not breaking compiler but behaviour) but do you think we'd upset a lot of code bases if we removed the method. hmm maybe obsolete the old one and keep it around for a while whether we introduce a new method or not?

@rickdotnet
Copy link
Collaborator

Safest bet, in my opinion, would be to mark it as obsolete and include a nudge in the right direction, either a new method or a link to docs.

mtmk added 2 commits January 20, 2025 15:51
Since we now support ad-hoc JSON serialization by default,
we can obsolete these methods. If there is interest, we
can create more suitable and more general builder methods
later on.
@mtmk
Copy link
Collaborator Author

mtmk commented Jan 21, 2025

Safest bet, in my opinion, would be to mark it as obsolete and include a nudge in the right direction, either a new method or a link to docs.

@rickdotnet sorry for the delay, this is done. let me know if you like the text goes with it - here

@mtmk mtmk added the priority label Jan 25, 2025
Copy link
Contributor

@scottf scottf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@mtmk mtmk merged commit d60ae29 into main Jan 27, 2025
13 checks passed
@mtmk mtmk deleted the 687-register-natsclient-to-di branch January 27, 2025 16:38
mtmk added a commit that referenced this pull request Jan 27, 2025
* Fix telemetry header readonly error (#719)
* Add NatsClient to DI (#689)
* Add callback to NatsAuthOpts that allows refreshing a Token (#712)
* Implement Lame Duck Mode Event Handler (#716)
* Add CreateOrUpdateStoreAsync (#707)
@mtmk mtmk mentioned this pull request Jan 27, 2025
mtmk added a commit that referenced this pull request Jan 27, 2025
* Fix telemetry header readonly error (#719)
* Add NatsClient to DI (#689)
* Add callback to NatsAuthOpts that allows refreshing a Token (#712)
* Implement Lame Duck Mode Event Handler (#716)
* Add CreateOrUpdateStoreAsync (#707)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Shouldn't NatsBuilder register NatsClient to DI?
3 participants