Support for GZIP compression for smaller payload JSON

[molBR]

Use case

The main problem when dealing with server driven is the payload that is much bigger than dealing with just plain data. This means a larger payload and more network usage when delivering content to a cellphone for example.

Proposal

The proposal is to build a GZIP converter interface to compress the sent data and save space, using less bandwitch. The frontend library would need to have a decoder to transform the compressed data to its original json type.

I am willing to implement the solution for the backend, but first I would like to know the opinion of the community, and gather some feedback about the idea

[Tiagoperes]

Hello @molBR! Thanks for sharing your idea!

We don't believe compression should be a responsibility of Beagle.

• In the backend, Beagle must make it possible for the developer to send the JSON data however he/she wants, including compressed with GZIP.
• In the frontend, Beagle must make it possible for the developer to consume the JSON however he/she wants, including a compressed GZIP.

This is the same case of authentication. The developer can implement Authenticated JSONs in the backend and frontend, but Beagle is not responsible for this. Beagle should worry only with building a JSON in the backend and consuming a JSON in the frontend. How this traffic happens depends entirely on the application.

But where to implement compression?

Backend

In your controller, before returning the json as the response body of the request, you can use the compression tool of your choice to compress the json.

In order to have control over the response, you can implement your controller like any non-beagle controller and then use the BeagleSerializationUtil to generate your json from the screen builder.

Frontend

In the frontend you must implement your own ViewClient which can be seen as a middleware for every request that produces a screen. This is a very simple class that implements two methods: fetch and prefetch. You can add the process of extracting the gzip here.

Contribution

Explaining this process with code examples would be an awesome addition to our documentation! We'd appreciate very much if after implementing this you could write some text about it so we can add it to our docs. This text can be written in either portuguese or english, we can add the translation later.

[Tiagoperes]

Hi, I'm passing here just to let you know that the Beagle team is taking some vacation time.

We'll take 2 weeks off and be back at Feb 06. Feel free to keep commenting in this issue and we'll address it as soon as we're back.

[molBR]

@Tiagoperes
I understand your point. What I meant was to develop a small interface that acts as an option on the library that, if the developer chooses to do so, the Beagle Library would compress the json payload. If no option is sent, the Screen Builder will deliver JSON as it is already delivered.

Basically, I understand that are three ways to dealing with this problem.

Reversed Proxy Server Compression

If you happen to have a Reversed Proxy in the backend, you can add a option on the proxy that compresses the json payload. This way, every BFFs and Apis that delivers big content json can have the data compressed with a single solution.

It would still need for the client to implement code to decompress the data, in every different plataform (Web, iOS, Android)

Compress after data is created

Maybe the simplest solution, just compress the data outputed by beagle and send to the client. And then decompress it and input the decompress to the Beagle Client. Its simple but not very efficient since that it would require a lot of code writing.

Library Built-In Option

This is the main purpose of this issue. In my opinion, one of the main drawbacks of server driven is the inflated payload that consumes a lot of internet of the client and server. Delivering a library solution would save the developer of writing a lot of code (backend and frontend) to handle with this kind of problem and make the library more reliable

I will try to implement these solutions to show it as a PoC to better understand the tradeoffs. Not sure it would be all done by feb 08 since I would be doing this in my spare time.

[Tiagoperes]

@molBR I don't see a problem in having this feature as an additional dependency that the user can easily enable/disable. It would make using gzip with Beagle very easy. I'm looking forward to your contribution!

[Tiagoperes]

Closing this due to inactivity.