3 ms·
The entire original post, it seems, is dedicated to explaining why Skir is better than plain Protobuf, with examples of all the well-known pain points. If these
by nine_k 8mo ago
The entire original post, it seems, is dedicated to explaining why Skir is better than plain Protobuf, with examples of all the well-known pain points. If these are not persuasive for you, staying with Protobuf (or just JSON) should be a fine choice.
- waynesonfire 8mo ago[flagged]
- nine_k 8mo agoIf you are fine enough with protobufs so that you're not actively looking for alternatives, maybe you should not spend the effort.
- gepheum 8mo ago+1 Copying from blog post [https://medium.com/@gepheum/i-spent-15-years-with-protobuf-then-i-built-skir-9cf61cc65631?postPublishedType=repub https://medium.com/@gepheum/i-spent-15-years-with-protobuf-t...]: """ Should you switch from Protobuf? Protobuf is battle-tested and excellent. If your team already runs on Protobuf and has large amounts of persisted protobuf data in databases or on disk, a full migration is often a major effort: you have to migrate both application code and stored data safely. In many cases, that cost is not worth it. For new projects, though, the choice is open. That is where Skir can offer a meaningful long-term advantage on developer experience, schema evolution guardrails, and day-to-day ergonomics. """