Client libraries are better when they have no API?

Original Article ↗ Hacker News Discussion ↗

A blog post about the CSV-hosting service csvbase and its Python client sparks debate over whether “no-API” client libraries—implemented as filesystem-style URL schemes via fsspec—are simpler or just a different kind of API. Commenters like the convenience of reusing existing tools (Pandas, Polars, etc.) by simply passing `csvbase://` URIs, but raise concerns about hidden plugin registration, debugging difficulty, and surprising differences between development and production environments. The thread also revisits long‑running arguments about what counts as an API, the trade-offs between explicit and “magical” integration patterns, and whether CSV is a sensible interchange format compared with JSON or Parquet.

What “no API” is arguing for

  • Many interpret “no API” as misleading, since HTTP endpoints and URI schemes are still interfaces.
  • Several commenters read the point as: avoid bespoke client libraries and new method surfaces; instead, integrate with tools and protocols users already know (e.g., Pandas’ read_csv) and let agent detection/content negotiation “do the right thing.”
  • Some find this elegant: you just use a csvbase:// URI; no extra client class or methods to learn. Others argue that this is still an API, just a very thin one.

fsspec plugin model and URI schemes

  • Discussion highlights how fsspec lets developers implement custom filesystems with minimal code and automatically expose them to multiple libraries (Pandas, Polars, Dask, DuckDB).
  • Enthusiasts like that installing a package adds support for a new URI scheme everywhere fsspec is used, enabling composition and ecosystem effects.
  • Skeptics worry that “pip install” silently changing runtime behavior via entry points is dangerous and surprising.

Hidden magic vs explicit configuration

  • Strong discomfort with hidden monkeypatching or plugin auto-registration: hard to discover, debug, or reason about, especially during outages or refactors.
  • Some prefer explicit registration calls or explicit passing of filesystem objects, even if slightly more verbose.
  • This is framed as “convention over configuration” versus “explicit is better than implicit”; several point out maintenance and debugging costs, action-at-a-distance, and unclear dependencies across time.

API ergonomics, access control, and payments

  • Several comments complain about “annoying APIs”: multiple keys, forced project/account setup, SMS 2FA, complex OAuth flows.
  • There is a side discussion about alternative payment and anti-abuse models (e.g., simple pay-per-call, crypto-based) versus identity-based accounts; no clear consensus.

CSV and data format trade-offs

  • Some praise CSV as convenient for tabular data and compatible with existing tools.
  • Others call CSV a “terrible” or underspecified format, citing ambiguity around nulls, escaping, separators, and newlines; they prefer JSON, JSON Lines, Parquet, or even XLSX.
  • Commenters note that none of the formats is ideal: JSON is verbose, CSV messy, Parquet complex and less stream-friendly.

General takeaways

  • Many like the article as a demonstration of building on existing abstractions instead of reinventing client libraries.
  • There is sharp disagreement on whether the convenience of auto-wired plugins and URI schemes is worth the hidden complexity for long-term maintenance.