search

fsprojects / FSharp.Json

F# JSON Reflection based serialization library
Apache License 2.0
226 stars 26 forks source link

Production ready? #1

Closed cmeeren closed 6 years ago

cmeeren commented 6 years ago

Just came across this on SO, and this library seems to have much of what I want from an F# JSON serialization library. I notice, however, that it's just gotten started, so I'm very reluctant to use this for any kind of serious work.

How production ready is this? I'm not just talking about how feature-complete or bug-free it is, but also the stability of the API, and not least the stability of serialization/deserialization. Specifically, if I use this library to persist data somewhere, then I want to be able to rehydrate it a month or a year down the line without errors using a new version of the library.

vsapronov commented 6 years ago

Hi Christer. I can promise that API and default behaviors won't be changed for some time. It gives you confidence that if you use simple features then you are safe. From the other side I would recommend you to pin the version of FSharp.Json that you are using. I made an effort to make sure that it does not depend on anything, so you can live on version 0.1 without any issues for a longer time.

cmeeren commented 6 years ago

One more question. If you ever change the default serialization, could you (at least for a time) include an option to use the old serialization behavior?

I ask because I might be using this for a web API and the mobile app that talks to this API, and since app updates are far from instantaneous, I must be able to upgrade FSharp.Json in the API while still supporting existing versions of the app (with existing versions of FSharp.Json). If FSharp.Json makes backwards-incompatible changes without any option to keep existing behavior, that would then stop me from ever upgrading FSharp.Json (since doing so would immediately break all existing app installations).

If you include an option to keep the old behavior, then I could use the old behavior for existing API routes and use the new behavior for new API routes. That would allow all existing app installations to continue working, and new app versions could use the new API routes, so I could remove the old routes (and the old serialization behavior) after some time.

vsapronov commented 6 years ago

Hi Christer,

Default behaviour will not change until version 2.0 for sure. This does not mean that it will necessary change in version 2.0. I'm pretty confident that both API and default behavior is good enough to stay not changed. If change will be required then it will be done only in new major version and I will try to keep previous behavior available by configuration option as long as it's possible it shouldn't be a problem.

Though needless to say that pinning libraries versions is overall good for code stability in production. Always upgrade with eyes wide open...

cmeeren commented 6 years ago

Though needless to say that pinning libraries versions is overall good for code stability in production.

Absolutely, and I will. :) But asynchronous updates in the app and API means that if the serialization changes without possibility for keeping the default behavior through configuration, then that effectively stops me from ever upgrading FSharp.Json to that version (I'm versioning my API, e.g. https://myApi.com/v1/..., but all versions are running in the same project/application, so all API versions must use the same version of FSharp.Json).

Great to hear that you think the default behavior is good enough to be kept stable for a good while. :)