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

System.Text.Json instead of Newtonsoft Json.NET? #7874

Closed
bill-poole opened this issue Jul 21, 2022 · 5 comments
Closed

System.Text.Json instead of Newtonsoft Json.NET? #7874

bill-poole opened this issue Jul 21, 2022 · 5 comments
Assignees
Labels
✔️ Resolution: Answered Resolved because the question asked by the original author has been answered. question Status: Resolved
Milestone

Comments

@bill-poole
Copy link
Contributor

It looks like a prior proposal to switch to System.Text.Json (STJ) from Newtonsoft Json.NET (#6070) was not accepted due to lack of support for polymorphism in STJ. However, it appears support has now been added for .NET 7. Should replacing Newtonsoft with STJ therefore be re-evaluated?

@ReubenBond
Copy link
Member

Orleans uses its own serialization framework for serializing messages between hosts (for good reasons) but has support to delegate to other serialition libraries. For that, it supports System.Text.Json and Newtonsoft.Json already, and gives users full control over how they're configured.

The two libraries are far from parity and will not be at parity for the foreseeable future because they are targeted at different scenarios. STJ is much lower-level and much more explicit than Newtonsoft.Json at a cost of developer-friendliness.

For persistence providers (distinct from wire serialization), we support pluggable serialization, but we still need to implement that for the remaining providers: #7810

@ReubenBond ReubenBond added the ✔️ Resolution: Answered Resolved because the question asked by the original author has been answered. label Jul 21, 2022
@ghost
Copy link

ghost commented Jul 21, 2022

Thanks for contacting us. We believe that the question you've raised has been answered. If you still feel a need to continue the discussion, feel free to reopen the issue and add your comments.

@ghost ghost added the Status: Resolved label Jul 21, 2022
@ghost ghost closed this as completed Jul 21, 2022
@bill-poole
Copy link
Contributor Author

Thanks @ReubenBond. Apologies I wasn't sufficiently specific - I was actually talking about persistence - specifically the DynamoDB provider. So if I understand you correctly, the position going forward for the DynamoDB persistence provider is to continue to use Newtonsoft as the default serializer, but allow a custom serializer to be configured, which would allow STJ to be used?

@ReubenBond
Copy link
Member

The position is that storage providers shouldn't be responsible for serialization. Instead, they should delegate that to IGrainStorageSerializer, which can have various implementations (one per storage provider). If there's a default, Newtonsoft.Json certainly provides a better experience than System.Text.Json out of the box. Is there any particular reason you'd prefer System.Text.Json be the default?

@bill-poole
Copy link
Contributor Author

I'm not particularly fussed about what the default storage serializer is as long as it is configurable. That being said, it would be nice to avoid unnecessarily packaging Newtonsoft Json.NET with my application. My primary concerns/interests wrt using STJ instead of Json.NET are:

  • Performance: STJ is a much higher performance serializer than Json.NET and I have a very data-intensive application (that writes a lot of data to storage in very fast bursts) where every CPU cycle is precious.
  • Consistency: I would like to avoid having some JSON serialized with STJ and the rest with Json.NET in my application because the two libraries can have different behaviours.

@ghost ghost locked as resolved and limited conversation to collaborators Aug 25, 2022
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
✔️ Resolution: Answered Resolved because the question asked by the original author has been answered. question Status: Resolved
Projects
None yet
Development

No branches or pull requests

3 participants