DEV Community: Peter Aleksander Bizjak

Shipping JSON over the wire is professional negligence

Peter Aleksander Bizjak — Fri, 19 Dec 2025 06:59:49 +0000

I can already see that this article is gonna piss off some folks. Fine by me.

Human-readable data in transit is a decades-old mistake we keep defending out of habit. Not because it’s correct. Not because it’s efficient. Because it’s familiar. JSON is the most familiar of them all, and that’s exactly the problem: we treat familiarity like a guarantee.

Yes, that's my opening salvo.

Instead of talking about "my feelings", here is the objective issue: JSON has no type safety. Not the way people mean it when they say "type safety". It has no schema. No enforced contract. No canonical representation. It is a string of bytes that both sides politely agree to interpret the same way... Until one side doesn’t.

"But we have documentation." Sure. Documentation is a story you tell humans. The wire is where truth lives. And on the wire, JSON does not enforce anything.

You can document that age is an integer. Then a client sends "age": "27" because JavaScript, and no one notices because you silently coerce it. Until you don’t. Or the server sends null where the client expected a number. Or the server "helpfully" changes snake_case to camelCase during a refactor. Or someone adds a field with the same name but a different meaning because it was "unused anyway". Or the backend returns "status": "ok" on a failure because the error path is duct-taped and the API gateway is lying for it. All of this is legal JSON. That’s the point. JSON will happily serialize your mistakes. JSON will not care. "It's meant to be simple".

Using no schema and relying on "flexibility" means that your contracts are always implicit, social, and enforced by good vibes. I'm sorry, but you can't expect to build a serious system on crossed fingers, holding hands and singing praises to the deity of choice.

This is also why "we’ll just validate it" is not an argument for JSON. It’s an admission. It means you need a second system! And you’ll keep doing it in every client, in every service, in every language. Repeatedly. Forever.

I'm not talking smack at developers of such validation libraries, in fact, we need strong validation logic anyways, regardless of the contract protocol, but not for the protocol itself. That's my whole argument.

With schema-driven formats, you can still mess up, but you have guardrails that exist outside of tribal memory. There is a schema. There is a canonical encoding. There are compatibility rules that are mechanical, not interpretive. You can’t "accidentally" ship a string where a number belongs without someone, somewhere, screaming early.

This is, of course, unless you use a language like JavaScript where types don't exist.

And yes, bytes matter too. Text is expensive in the boring ways: field names repeated, quotes repeated, escapes repeated, parsers doing work they shouldn’t have to do, allocations that multiply under load. For what? So that someone can reach for the comfort blanket: debugging. If the best defense of JSON is "I like reading it with my eyes", I cannot put this mildly, you’re optimizing for the wrong thing, and you've missed the plot entirely. Debugging should be done with tools that understand the contract, not with eyeballs scanning a blob and praying you didn’t miss a comma. We have better tooling for contract-driven protocols than "copy as cURL, pipe to jq, and squint".

So here’s the actual recommendation: make a schema format, such as Protocol Buffers, Avro, or another schema-driven system, the canonical representation between machines. Use JSON only where it is genuinely appropriate.

And if you’re still offended by that: good. You should be. Not at me, though! Be offended at the fact that we collectively decided "a bag of untyped strings with vibes" is an acceptable foundation for systems we claim are serious. Keep JSON as your duct tape if you want. Just don’t call it architecture. And definitely don’t call it "type safe" with a straight face, and pretend that your cute GraphQL schemas are sufficient.

I'm not going to tell you to drop everything and get familiar with Protocol Buffers and gRPC, but I'm also not going to tell you not to.

Vibe Coding ++

Peter Aleksander Bizjak — Mon, 10 Nov 2025 06:08:09 +0000

Originally published on my blog.

The arrival of any new technology always creates two camps: those who embrace it and those who reject it. While voices in the middle exist, they’re less vocal and often overlooked. Being reasonable isn’t nearly as attention-grabbing.

When AI became commercially available in a user-friendly way (think ChatGPT), people quickly split into two camps: one predicted mass job loss within months (though we're years past that now), while the other viewed AI as a technological savior set to resolve every problem and replace humans entirely.

Turns out... Both camps are right! In Europe and North America, the white-collar job market in 2025 shows elevated unemployment (EU: 6.2%; US hiring at weakest since 2009) and widespread layoffs (e.g., Amazon's 14,000 cuts), driven by a mix of factors. AI does have a role in that. It did accelerate displacement, especially in entry-level roles (40% of employers plan reductions; potential 10-20% unemployment spike), via automation in tech, finance, and admin. It's amplifying vulnerability, but not the primary driver yet. Dominant causes include recession signals, slowing growth, high borrowing costs, inflation, and US tariffs hitting Europe, displacing cca. 1.6M jobs globally. AI exacerbates but trails these structural issues.

So that means that people are losing jobs, and/or not being able to get them, and that higher-ups have managed to find a solution to their problem by cutting down costs of labor and replacing it with AI. But then again, being a voice in the middle is boring. Why am I even trying to be factual here and not rage-bait for clicks? Ugh, silly me!

When AI-assisted coding became attainable to developers via IDEs such as Cursor, productivity jumped immensely. Even in the earliest stages, we all knew that software engineering was going to change forever. Before IDEs like Cursor, you had to copy-paste code from your text editor to ChatGPT/Cursor chatbot, and hope you didn’t exceed the context window. Nowadays, you can instruct a model to review your codebase, make a plan, align on requirements with you in a collaborative fashion, and execute it.

At that point, we, once again, ended up with two camps. On one end, you had so-called “vibe coders”, people who blindly trust AI. On the other hand, hardcore AI rejectionists. The puritans of software engineering, if you wish. In this case, I can’t say that both camps are justified in their own way, but the truth is that the job of software engineering is somewhere in between. There are tasks that you can absolutely delegate to AI. And there are tasks that you simply can’t. Not because AI is not good enough, or will not get good enough in the future, but because you cannot replace the human element in certain tasks and jobs with a machine.

Again, what’s up with all that middle-ground exasperation? Make up your mind!

Humans tend towards comfort over harsh conditions for life. That’s why we innovate and adapt the environment to our liking. So it’s not a surprise that vibe coding, the practice of using AI as a replacement for doing the hard work of thinking, reasoning, and working, is the default preference. The only problem with AI-written code is the fact that AI models are prone to hallucinations, bad/obsolete training data, and often miss the aforementioned human decision-making and forward-thinking component. The result? Bedraggled code.

LinkedIn saw the emergence of “Vibe coding cleanup specialists”. I’m pretty sure there is a demand for such workers. Because if vibe coding is the future of software engineering, then at some point, there will be an emergence of a movement that wants to adhere to best practices in AI-written code, including writing tests and following battle-tested design patterns. And that’s the influence of the AI-rejectionists/manually-written-code puritans camp. Humans have been working with technology for far longer than AI has been around. You can read all about tech, and you can ingest all the knowledge in the world, but you’ll never be able to beat experience. You’ll never be able to beat intuition born through hard work and getting burned by mistakes.

The idea will be peddled as self-healing AI-written code.

Code is supposed to be read; writing it is easy. Code is supposed to execute and perform necessary functions, and in order for you to know that’s the case, you need to test it. At some point, you’ll have to make changeovers, so wouldn’t it help if code were designed in a way where modifications can be gradual, incremental, and isolated? So this is where I’m making my stand. AI-written code will have to follow certain principles of “clean” design (which I know is a triggering word for some), and it will have to be well-tested and validated before being given to humans for review.

All of this will demand skills and a deep understanding of the technology one works with. Yes, AI can write a lot of code very fast, and most likely, this code is better than what you would write manually. The only metric of how “good” a code is, is whether or not it passes tests (which you still have to orchestrate and understand how to write), and whether or not it’s written in a way that’s easy to understand and follows battle-tested design patterns. This is where humans come in. It’s your experience, it’s your talent, it’s your skills, all put in a line. How well can you communicate, how clear can your instructions be, how well can you predict future edge-cases... No amount of AI assistance can help you with that. This takes years of practice, which nobody (and nothing) can replace.

Keep shipping.

Golang for FFI Flutter Plugins

Peter Aleksander Bizjak — Sun, 01 Jun 2025 17:02:36 +0000

If you've ever developed applications with Flutter, you've probably pulled a package from pub.dev that uses FFI (foreign function interface). These packages call native C APIs and handle all the basic memory management tasks. I'll not delve too deep into details on C interop using dart:ffi in this article, for that, you should simply read the official documentation.

Programming languages you'd typically associate with the creation of such packages are, well, kinda obviously, C and C++. However, the conditions for developing an FFI Flutter plugin are fairly straightforward: the language must support creating libraries that can be compiled into binary format, these binaries must be compatible with the target platform, and they need to support C/C++ interop. Technically speaking, the C interop is the important one. You can mix C and C++, but you have to be aware of what you're doing.

Besides the usual suspects, Rust comes up in the discussion quite a bit. Funny enough, many FFI-based packages use Rust nowadays. Since I'm not experienced with Rust (beyond being able to write a hello world program and read Rust code with the help of AI), I cannot comment much on the viability of the language for that particular task. As far as I'm aware, flutter_rust_bridge is a popular choice. Other than C, C++, and Rust, I would imagine that Zig would be a good candidate as well. However, the language and its community are fairly small (as far as I know, Bun.sh is the only Zig's flagship project), so I'm not sure how many Flutter developers even know about it, let alone use it.

So what about Go?

Background

First time I heard of Go was in 2019, and at the time, I was not interested in system programming. Sure, as a student researcher, I worked extensively with C (and to a certain extent with C++), but the language never really drew my attention until sometime in 2022 when I was evaluating an alternative to Nest.js-based microservice. The reason was mostly memory footprint and ease of deployment. I spent a few hours going through the language tour, and found the language extremely easy to work with.

But I only saw the usability of Go as an alternative to Python for scripting/CLI application development, and obviously for backend development. Especially when it comes to gRPC (but that's a story for another time). I never looked at Go as an option for the development of FFI Flutter plugins, until sometime last year, I got acquainted with Tailscale. Tailscale has built its products around Go, including mobile applications. For reference, I'd strongly encourage you to check the source code of their Android client and the Swift library inside the main libtailscale repository. So, somebody did it... A successful company uses Golang for its clients.

Experiment

The big picture of my experiment is simply this:

Create an FFI Flutter plugin that uses Golang, supporting Android and iOS
Create a simple proof-of-concept application that's not a dumb hello world app or a default "sum of two numbers" example.

With that in mind, I set out to develop an RSS reader application called RSSit.

Prerequisites

Before doing anything, let's go over prerequisites:

We need to make sure that Golang supports C interop
Can produced binaries be used in Android or iOS applications, and what build tool will be used?
How to efficiently pass (what might end up being) a large amount of data between Go and Dart?

So let's tackle those one by one.

C, Go, and Cgo

There's a thing called Cgo. Cgo enables the creation of Go packages that call C code. I'm not going to discuss Cgo in detail, as their official documentation should be enough for anyone to get started.

One important note here: because we'll be using Cgo and Go's built in compiler, there's no reason to rely on Clang. The only file left from the default example was the header file declaring exports of compiled libraries, something used by ffigen package to produce Dart bindings.

Native libraries in Android and iOS

For Android, we'll need to use NDK and produce a dynamic library for each CPU architecture. For iOS, we'll produce static libraries + corresponding header files.

Wait... How do you know that?

Simple. What's the difference between shared and dynamic libraries? Statically linked libraries copy all the library modules used in the program into the final executable image, while dynamically linked libraries load the external shared libraries into the program, binding them to the final image.

Because we're dealing with Cgo, setting CGO_ENABLED=1 is going to be a must. This environment variable controls whether the Cgo tool is used during the build process (which, yes, it is). It determines if Go code can interact with C code and libraries (which, yes, it has to).

Android apps load native libraries dynamically at runtime. iOS applications, on the other hand, are distributed as single bundles, meaning all code has to be included.

When building the Go library, deciding between static/dynamic libraries is handled using buildmode.

For static libraries, use -buildmode=c-archive
For dynamic libraries, use -buildmode=c-shared

For Android, multiple CPU architectures have to be supported (ARMv7, ARM64, x86, x86_64). You set the architecture using GOARCH and the operating system using the GOOS environment variables. On top of that, the CC environment variable should link to Android NDK compiler.

#!/usr/bin/env bash
set -euo pipefail

# Library configuration
PROJECT_NAME="rss_it_library"
LIB_NAME="lib${PROJECT_NAME}"
PREBUILD_PATH="../prebuild/Android"

# Build mode configuration
BUILD_MODE="${1:-release}"
GO_BUILD_FLAGS="-trimpath -ldflags=-s"

# Detect OS for NDK path
NDK_VERSION="27.0.12077973"
if [[ "$OSTYPE" == "linux-gnu"* ]]; then
  ANDROID_HOME="${HOME}/Android/Sdk"
  NDK_PLATFORM="linux-x86_64"
elif [[ "$OSTYPE" == "darwin"* ]]; then
  ANDROID_HOME="${HOME}/Library/Android/sdk"
  NDK_PLATFORM="darwin-x86_64"
elif [[ "$OSTYPE" == "msys" || "$OSTYPE" == "win32" ]]; then
  ANDROID_HOME="${LOCALAPPDATA//\\//}/Android/Sdk"
  NDK_PLATFORM="windows-x86_64"
else
  echo "Unsupported operating system: $OSTYPE"
  exit 1
fi

# Check if NDK exists
NDK_BIN="${ANDROID_HOME}/ndk/${NDK_VERSION}/toolchains/llvm/prebuilt/${NDK_PLATFORM}/bin"
if [ ! -d "$NDK_BIN" ]; then
  echo "Error: Android NDK not found at ${NDK_BIN}"
  echo "Please install Android NDK ${NDK_VERSION} or update the script with your NDK path"
  exit 1
fi

echo "Using Android NDK at: ${NDK_BIN}"
echo "Building ${PROJECT_NAME} for Android..."

# Function to build for a specific architecture
build_for_arch() {
  local arch="$1"
  local goarch="$2"
  local cc="$3"
  local dir_name="$4"
  local goarm="${5:-}"

  echo "Building for ${arch}..."

  # Create output directory
  mkdir -p "${PREBUILD_PATH}/${dir_name}"

  # Set environment variables
  export CGO_ENABLED=1
  export GOOS=android
  export GOARCH="$goarch"
  [ -n "$goarm" ] && export GOARM="$goarm"
  export CC="${NDK_BIN}/${cc}"

  # Build the library
  go build $GO_BUILD_FLAGS -buildmode=c-shared \
    -o "${PREBUILD_PATH}/${dir_name}/${LIB_NAME}.so" .

  # Remove header file
  rm -f "${PREBUILD_PATH}/${dir_name}/${LIB_NAME}.h"

  echo "Successfully built for ${arch}"
}

# Build for all architectures
build_for_arch "ARMv7" "arm" "armv7a-linux-androideabi21-clang" "armeabi-v7a" "7"
build_for_arch "ARM64" "arm64" "aarch64-linux-android21-clang" "arm64-v8a"
build_for_arch "x86" "386" "i686-linux-android21-clang" "x86"
build_for_arch "x86_64" "amd64" "x86_64-linux-android21-clang" "x86_64"

echo "Android build complete. Libraries are in ${PREBUILD_PATH}"

On iOS, we only need to support two architectures (x86_64 and ARM64), we use Xcode command line tools and the Clang compiler (set to CC environment variable). I rely on lipo to create a universal library, which is something you need to support iPhone Simulators.

#!/usr/bin/env bash
set -euo pipefail

# Check if running on macOS
if [[ "$OSTYPE" != "darwin"* ]]; then
  echo "Error: This script must be run on macOS"
  exit 1
fi

# Library configuration
PROJECT_NAME="rss_it_library"
LIB_NAME="lib${PROJECT_NAME}"
PREBUILD_PATH="../prebuild/iOS"

# Build mode configuration
BUILD_MODE="${1:-release}"
GO_BUILD_FLAGS="-trimpath -ldflags=-s"

# Check for Xcode tools
if ! command -v xcrun &> /dev/null; then
  echo "Error: Xcode command line tools not found"
  echo "Please install Xcode command line tools with: xcode-select --install"
  exit 1
fi

echo "Building ${PROJECT_NAME} for iOS..."

# Minimum iOS version
MIN_IOS_VERSION="11.0"

# Function to build for a specific architecture
build_for_arch() {
  local sdk="$1"
  local goarch="$2"
  local carch="$3"
  local device_type="$4"

  echo "Building for ${device_type} (${carch})..."

  # Create output directory
  mkdir -p "${PREBUILD_PATH}/${sdk}/${carch}"

  # Get SDK path
  SDK_PATH=$(xcrun --sdk "${sdk}" --show-sdk-path)

  # Set target triple
  if [ "$sdk" = "iphoneos" ]; then
    TARGET="${carch}-apple-ios${MIN_IOS_VERSION}"
  else
    TARGET="${carch}-apple-ios${MIN_IOS_VERSION}-simulator"
  fi

  # Find Clang compiler
  CLANG=$(xcrun --sdk "${sdk}" --find clang)

  # Set environment variables
  export GOOS=ios
  export CGO_ENABLED=1
  export GOARCH="${goarch}"
  export CC="${CLANG} -target ${TARGET} -isysroot ${SDK_PATH}"

  # Build the library
  go build ${GO_BUILD_FLAGS} -buildmode=c-archive \
    -o "${PREBUILD_PATH}/${sdk}/${carch}/${LIB_NAME}.a" .

  # Remove header file
  rm -f "${PREBUILD_PATH}/${sdk}/${carch}/${LIB_NAME}.h"

  echo "Successfully built for ${device_type} (${carch})"
}

# Build for each platform
build_for_arch "iphonesimulator" "amd64" "x86_64" "iOS Simulator"
build_for_arch "iphonesimulator" "arm64" "arm64" "iOS Simulator (Apple Silicon)"
build_for_arch "iphoneos" "arm64" "arm64" "iOS Device"

echo "iOS build complete. Libraries are in ${PREBUILD_PATH}"

# Ask if user wants to create a universal library
read -p "Create universal library for simulators? (y/n): " create_universal
if [[ "${create_universal}" == "y" ]]; then
  echo "Creating universal library for simulators..."

  # Create universal directory
  UNIVERSAL_DIR="${PREBUILD_PATH}/iphonesimulator/universal"
  mkdir -p "${UNIVERSAL_DIR}"

  # Create universal binary
  lipo -create \
    "${PREBUILD_PATH}/iphonesimulator/x86_64/${LIB_NAME}.a" \
    "${PREBUILD_PATH}/iphonesimulator/arm64/${LIB_NAME}.a" \
    -output "${UNIVERSAL_DIR}/${LIB_NAME}.a"

  echo "Universal library created at: ${UNIVERSAL_DIR}/${LIB_NAME}.a"
fi

Finally, in both cases GO_BUILD_FLAGS="-trimpath -ldflags=-s" is used to reduce the binary size by trimming paths and stripping debugging symbols.

Efficient data serialization/deserialization

Probably the last thing you wanna do is marshal the response to a JSON string, and send it over, only to be decoded on the Dart side. Sure, if your JSON looks like a simple {"status": "success"}, but RSS/Atom/JSON feeds, especially if [arsing] a large number of them, will produce a massive JSON object.

Not just for this purpose, but in general, I'm against the idea of using human-readable data format for data in motion. There's absolutely no reason for us to rely on JSON in 2025, when we have efficient protocols, like protocol buffers, that use a binary format (aka the wire format).

Let's do a short Q&A with some of the questions I've been asked in regards to the opinion above.

"Oh, but how do you test your backends in that case?" If you're only manually testing your backend code with Postman, Insomnia, or whatever HTTP client out there, you're doing something wrong. Your backend should contain automated tests, and (of course) manual QA. With that being said, Postman and Insomnia allow you to work with gRPC, and they will render the response in a human-readable format. Same with grpcurl.
"But what about web application? gRPC uses HTTP/2, which is not yet supported!" Just make a proxy.
"But JSON is a de facto standard, we can't just expect everyone to move over to something else?" XML was a standard before JSON. Many of you who grew up only knowing JSON probably have no clue what SOAP is. Point being, standards, consensuses, and trends change.
"But there's too much overhead associated with protocol buffers, I need so many extra steps!" The only "extra step" is writing a common contract between clients and servers, and using a protoc compiler to generate client/server code. Besides, speaking of overhead: let's talk about data serialization/deserialization, having to generate OpenAPI specifications, perhaps use a code generator to produce client code from the .json specification file, and don't get me started on request/response validation, streaming requests, SSE, ...
"But it's a whole new language to learn!" Web developers have no problem learning Prisma, but will cry about protocol buffers, whose syntax is much easier to get a hang on (took me a few minutes to get a grasp of it).

Use of goroutines

I was initially worried about whether or not my heavy reliance on goroutines would have any impact and/or would break when used in Flutter FFI, but after doing a bit of digging, I realized that goroutines are compiled into lightweight threads managed by Go's runtime, embedded in the library.

What are my main takeaways?

During this experiment, I learned a few valuable lessons. If I had to produce an executive summary:

Go is a viable language for the development of FFI Flutter plugins
Using protocol buffers pays off, as it gives me a common contract between Go and Dart, and the efficient data serialization/deserialization is worth the setup
I believe that my setup is easily replicable for any use case

As I mentioned in one of my long Twitter threads, the argument of "pick the right tool for the job", which is something I completely stand behind, in my opinion easily applies here. I don't think this experiment should be taken as "everyone needs to start using Go for the development of FFI Flutter plugins", but rather "here's an option".

I'm pretty sure there's a lot of great libraries developed in Go (or there's a lot of great engineers who could produce great libraries in Go). Opening the doors to using Go, and its extensive ecosystem, in Flutter application development, has a bunch of positive implications.