Strategies for sharing data with Fable frontend apps

[alfonsogarciacaro]

As Saturn will become the S in SAFE pretty soon and we want to also release Fable 2 in the upcoming weeks, it'll be good to start writing down ideas on how to easily communicate between the server and client sides to increase the value of full-stack F#.

Right now most of the users (myself included) are using Fable ofJson/toJson with the Fable.JsonConverter on the server side. However Fable 2 alpha will be released initially without reflection support in order to have lighter types and reduce bundle sizes (reflection may be added later depending on the feedback from users). Because of that, we're planning to promote @MangelMaxime Thot.Json for data exchange. It doesn't serialize types automagically, but it gives more control to developers and better validation. Maxime has also adapted it recently to server side.

Thot will soon also include helpers for Http requests which will improve the current Fetch bindings (not really nice in F# when building complex queries), and we can try to provide a similar API on the server side. Maxime already sent a proposal to Http.fs (see haf/Http.fs#142) but it may make sense to add it directly to Saturn.

Any thoughts on this, @Krzysztof-Cieslak @forki?

[forki]

It doesn't serialize types automagically

what does that mean? I can't just serialize a deep record and deserialize it?

[MangelMaxime]

@forki This mean that Thot.Json is more like Chiron.
You need to teach it how to do it:

open Thot.Json.Decode

type Point =
    { X : int
      Y : int }

    static member Decoder =
        decode
            (fun x y ->
                { X = x
                  Y = y } : Point)
            |> required "x" int
            |> required "y" int

> decodeString Point.Decoder """{"x": 10, "y": 21}"""
val it : Result<Point, string> = Ok { X = 10; Y = 21 }

Thot documentation

The benefit, is that it will make sure the types given are correct. And don't fail silently on some case fable-compiler/Fable#1344

We now that not everyone like Thot or Chiron approach. For Fable 1, it was just another alternative way to go things. For Fable 2 alpha, it's will probably the only way either temporary or for ever if we consider it better like Elm do.

We have plan for the future to generate the Decoder/Encoder. Still in very early stage :)

[forki]

if we remove the auto-serializing then this will hurt us in very dramatic ways. It will basically stop us from upgrading fable and we will see a divide in the ecosystem.

[Nhowka]

Could we have a base helper class that has some encoder/decoder method that would generate a compile-time default on Fable but has the reflection based behavior when running on the server? That would be faster than hand rolling every encoding and ease the migration.

[isaacabraham]

Could it be a setting that we could turn off / on (or provide somehow a custom serialization routine - the same sort of thing we've just gone through with Giraffe)?

Also - I'm of the opinion that documentation (opinionated or otherwise) for these sorts of things - integration between Fable, Suave, Giraffe, Saturn, etc. etc. - should live on the SAFE site. What do you think?

[robkuz]

I am totally for more control over the process BUT I would definitely keep the "default" one as it is

[MangelMaxime]

Because I shared my opinion on Twitter I copy/paste it here :)

I believe both should exist.

When you are using F# on the front end and back end it make sense to use auto serializer because you share the same code.

When depending on an external API or a server in another language we should use custom serializer like Thot.Json to secure data

[Krzysztof-Cieslak]

I really believe that typesafe, automatically serialized communication between SAFE layers is really important and can be one of the selling points of the stack. So we need to be sure that it’s still there, and that developers experience around that is great

[Krzysztof-Cieslak]

In perfect world the serialization, and communication can be abstracted by framework, just like Fable.Remoting does it

(Please, bear in mind that’s opinion from point of view of using “full” SAFE stack, I do agree that just from Fable perspective it may be good idea to have different approach to serialization)

[alfonsogarciacaro]

I opened the issue initially here in case Saturn could include something to automate communication with Fable apps, but @isaacabraham is right that this kind of things are probably better discussed under the SAFE umbrella.

However, the discussion has moved fast to JSON serialization in Fable specifically, so I opened a new issue with more information here: fable-compiler/Fable#1352

Please feel free to close issue if you prefer to continue the discussion there :)

[isaacabraham]

Can we close this issue? I would suggest that the current defaults in the SAFE template are pretty good:

1. If Fable.Remoting is used, it takes care of the serialization (I personally have no idea what it does behind the scenes, but it works!).
2. If Fable.Remoting isn't used, we turn on Fable's JSON serializer on the server side and remove the default Newtonsoft one with it. This then works with e.g. json HTTP Handler in Giraffe and Fable's Fetch() function.
3. If you need more fine grained control, you can easily stop using the serializer and replace with your own implementation e.g. Thot etc.