aeson-schemas VS schematic

Compare aeson-schemas vs schematic and see what are their differences.

aeson-schemas

Easily consume JSON data on-demand with type-safety (by brandonchinn178)

schematic

type-safe JSON spec and validation tool (by typeable)
Our great sponsors
  • WorkOS - The modern identity platform for B2B SaaS
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • SaaSHub - Software Alternatives and Reviews
aeson-schemas schematic
3 2
48 84
- -
7.0 0.0
about 1 month ago about 3 years ago
Haskell Haskell
BSD 3-clause "New" or "Revised" License GNU General Public License v3.0 or later
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.

aeson-schemas

Posts with mentions or reviews of aeson-schemas. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2022-04-10.

schematic

Posts with mentions or reviews of schematic. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2022-04-10.
  • A review of JSON Schema libraries for Haskell
    3 projects | dev.to | 10 Apr 2022
    schematic: Last updated in 2021. "It can be thought of as a subset of JSON Schema", "Schematic schemas can be exported to json-schema".
  • Buf raises $93M to deprecate REST/JSON
    6 projects | news.ycombinator.com | 8 Dec 2021
    Thanks for Cap'n Proto. I think the article is clearly indicating the issues that a wider community of conventional type systems in their mainstream languages is not fully aware of. And I disagree with your comments. Firstly, I don't like that you are labelling the author of the article as a "PL design theorist who doesn't have a clue":

    > his article appears to be written by a programming language design theorist who, unfortunately, does not understand (or, perhaps, does not value) practical software engineering.

    I'm not the author, but they mention their prior industrial experience at Google with protobufs.

    I'm not a PL theorist either, and I see that you don't fully understand the problems of composability, compatibility, and versioning and are too eager to dismiss them based on your prior experience with inferior type suystems. And here's why I think it is:

    > > This is especially true when it comes to protocols, because in a distributed system, you cannot update both sides of a protocol simultaneously. I have found that type theorists tend to promote "version negotiation" schemes where the two sides agree on one rigid protocol to follow, but this is extremely painful in practice: you end up needing to maintain parallel code paths, leading to ugly and hard-to-test code. Inevitably, developers are pushed towards hacks in order to avoid protocol changes, which makes things worse.

    You are conflating your experience with particular conventional tooling with the general availability of superior type systems and toolings out there. There's a high demand in utilising their properties in protocol design today.

    Version negotiation is not the only option available to a protocol designer. It is possible to implicitly migrate and up/down-cast schemas in semi-automated way. Example [1]

    > This seems to miss the point of optional fields. Optional fields are not primarily about nullability but about compatibility. Protobuf's single most important feature is the ability to add new fields over time while maintaining compatibility.

    There are at least two ways to achieve compatibility, and the optional fields that expand a domain type to the least common denominator of all encompassing possibilities is the wrong solution to this. Schema evolition via unions and versioning is the proper approach that allows for automatic resolution of compatibility issues.

    > Real-world practice has also shown that quite often, fields that originally seemed to be "required" turn out to be optional over time, hence the "required considered harmful" manifesto. In practice, you want to declare all fields optional to give yourself maximum flexibility for change.

    This is false. In practice I want a schema versioning and deprecation policies, and not ever-growing domain expansion to the blob of all-optional data.

    > It's that way because the "oneof" pattern long-predates the "oneof" language construct. A "oneof" is actually syntax sugar for a bunch of "optional" fields where exactly one is expected to be filled in.

    this is not true either, and it doesn't matter what pattern predates which other pattern. Tagged unions are neither a language construct nor a syntax sugar, it's a property of Type Algebra where you have union- and product-compositions. Languages that implement Type Algebra don't do it to just add another fancy construct, they do it to benefit from mathematical foundations of these concepts.

    > How do you make this change without breaking compatibility?

    you version it, and migrate over time at your own pace without bothering your clients too often [1]

    [1] https://github.com/typeable/schematic#migrations

What are some alternatives?

When comparing aeson-schemas and schematic you can also consider the following projects:

canonical-json - Canonical JSON for signing and hashing JSON values

aeson-combinators - Aeson combinators for dead simple JSON decoding

aeson-decode - Easy functions for converting from Aeson.Value

jsonpath - Haskell implementation of JSONPath

waargonaut - JSON decoding/encoding/manipulation library.

aeson-yaml - Encode any Aeson (JSON) value as YAML (in pure Haskell)

jsonifier - Fast and simple JSON encoding toolkit

aeson-typescript - Generate TypeScript definition files from your ADTs

one-line-aeson-text - Pretty-printing short Aeson values as text

safe-json - Automatic versioning of JSON formats for Haskell data types (with backwards compatibility)

rules_proto - Bazel build rules for protobuf / gRPC (now with gazelle)

wasp - The fastest way to develop full-stack web apps with React & Node.js.