Jorge Coca’s Post

View profile for Jorge Coca

Head Of Engineering @ Very Good Ventures | Design, Build, and Scale Successful Flutter Apps |

The software development world sometimes presents interesting and conflicting challenges: while some of the most important OOP languages have adopted null-safety as a standard (Kotlin, Dart, Swift...), we still rely on JSON to exchange data over the wire, which is not null-safe and unstructured. While there are alternatives to JSON, it is present in the majority of APIs available. In my experience, many of the quality problems apps experience these days are related to a misunderstood API contract with JSON as a guilty actor. JSON is great for flexibility, but the languages mentioned above are going in a different direction. Will we ever see an alternative to JSON that is structured, null-safe, and mainstream? Is someone already working on such a project? I would love to hear your thoughts!

I wouldn’t say JSON is the issue to break null-safety, instead it’s the careless developers that don’t waste resources in defining data contracts in their APIs to make sure both ends understand each other. JSON Schema is a really good tool for this. People say Protobuf is superior to JSON as both ends always understand each other, but thats just something that comes ootb with gRPC. They tend to forget they can achieve this with any data exchange protocol, as long as data contracts are defined.

Rafael Sandoval Jorquera

Senior Flutter Developer | Cross-Platform Mobile

8mo

I would love to see protobuf in the business

Like
Reply
Klodjan Lula

Senior Software Engineer +/- AI

8mo

Valid point! Somehow backend should send also the types 👍 In my case enforcing the backend to send an empty String is working great. But int and double are not that easy… Btw sending a null value is just stupid if we can have an empty string or zero value for number 👌

Like
Reply
Abhishak Kr. Malviya

Everything mobile @Pocketful

8mo

Please correct me if I'm wrong. Suppose you have a property which can be null but, instead of using null you have opted for providing a default value. Ex: you have a property called phoneNumber, this property will keep the phoneNumbers of the user. Instead, you kept a default value of 9999999999 and you have written logic on the UI if the phoneNumber is the same as the default value then don't show that UI but, someday a user entered the same number. Ideally you should show the UI but because it is the same as the default value you won't. The example might be confusing but I hope it will make you understand what I want to explain.

See more comments

To view or add a comment, sign in

Explore topics