[HN Gopher] Why we created Taxi, and why we felt the need for an...
___________________________________________________________________
Why we created Taxi, and why we felt the need for another schema
language
Author : martypitt
Score : 36 points
Date : 2023-05-15 10:48 UTC (1 days ago)
(HTM) web link (orbitalhq.com)
(TXT) w3m dump (orbitalhq.com)
| sfvisser wrote:
| Couldn't quickly find it, but does it support enums/sum types?
| martypitt wrote:
| Enums, yep: https://taxilang.org/language-reference/types-and-
| models/#en...
|
| Sum types, no, not yet.
| dang wrote:
| I think there was a related thread about this in recent weeks but
| I can't find it. Anyone?
| martypitt wrote:
| Taxi was discussed 12 months ago here:
|
| https://news.ycombinator.com/item?id=31524950
| AlexITC wrote:
| Not sure if others are aware, there is an Esoteric language
| called Taxi (https://esolangs.org/wiki/Taxi).
| swalsh wrote:
| This is super interesting, it's like a single spec for your
| entire enterprise architecture.
| hurril wrote:
| The examples all look like something I can do today in any modern
| functional language. What if I told you that you do not have to
| stick with Java or C#?
| speedbird wrote:
| ASN.1 anybody?
| hhthrowaway1230 wrote:
| i love how graphql described its types in its dsl, thats one of
| things id love to see carried over in other schema formats. it
| looks like taxi tries to do this to some extend
| martypitt wrote:
| A descriptive type system is a big part of what makes Taxi
| work.
|
| We took a lot of inspiration from GraphQL (because it's
| awesome), but I actually think we go further in the type system
| than GraphQL.
| [deleted]
| philipodonnell wrote:
| > Taxi shifts the obligation of describing how things stitch
| together from Consumers to Producers. Traditionally, it falls to
| consumers to work out how to do this. And, it's an expensive
| question to answer... it involves tracking down API specs,
| reading docs, and building a mental model of how things hang
| together.
|
| I work on enterprise data platforms and this project sounds very
| much like the "data mesh" concept where responsibility for
| defining metadata/usability of datasets is supposed to rest with
| the teams producing the datasets rather than the teams consuming
| datasets. The same criticism probably applies:
|
| * Even though it is expensive/slow for a consumer to figure out
| how to use data, it is even more expensive/slow to have producers
| try to continuously anticipate the needs of all possible current
| and future consumers, rather than focus on their system and have
| actual consumers figure out how to use the subset of data they
| need as it changes.
|
| * Above a Dunbar-esque-sized organization you can no longer rely
| on empathy to encourage producers to expend extra effort on
| consumer's needs, so either monetary or disciplinary
| encouragement is needed, both of which raise costs even further.
|
| Is there a name for this kind of paradox? When an approach will
| work only in a company below a certain size/complexity/age, but
| that kind of company probably doesn't feel the pain enough to
| need the approach?
| martypitt wrote:
| > it is even more expensive/slow to have producers try to
| continuously anticipate the needs of all possible current and
| future consumers
|
| I agree, but I don't think Taxi encourages that. (I sure hope
| it doesn't).
|
| All that's really happening is defining a system-agnostic set
| of terms, embedding those in producer schemas, and then letting
| consumers using those same terms to ask for data.
|
| Those terms can be used to automate integration, and in many
| (but not all) cases, alleviate the need for low-value plumbing
| code.
|
| Semantic Metadata is a growing trend in the data ecosystem
| (cube.dev is doing a nice job here too). The Agile folks have
| had Ubiquitous Language as a first class concept since day dot.
|
| > an approach will work only in a company below a certain
| size/complexity/age I think that GraphQL federation is an
| example of mid-to-large companies trying to solve the
| federation problem, suggesting they both feel the pain, and are
| looking for solutions.
| mst wrote:
| The goals of Taxi feel at least somewhat like 'creating a
| domain driven design style Ubiquitous Language to describe
| data and relationships' and the deliberate not-forcing-a-
| single-global-thing seems like it'll at least make it harder
| for enterprise dysfunction to bend it into having the failure
| modes the grandparent describes.
| cgio wrote:
| What happens when a consumer does not understand the
| producer's domain and misuses the data? As we load metadata
| with semantics of their own, we just kick the can down the
| road. Metadata is itself semantics about data. In many
| regulated environments, as producer you are responsible for
| downstream aggregations etc. I think the idea works great in
| prototyping, but similar to data mesh, ownership is poorly
| defined in the presence of aggregate domains and it's more
| tuned to operational point to point interfaces.
| davidy123 wrote:
| It's a shame they didn't mention Hydra. https://www.hydra-
| cg.com/spec/latest/core/
|
| This is designed to let data be exchanged richly between sites,
| and comes from the earliest ideas of the web, it is the HATEOAS
| part of REST.
| obi1kenobi wrote:
| I've had my eye on Taxi for a while, and it's neat! I agree that
| the problems it aims to solve are real and painful in real life.
|
| In my experience, I'm not sure people care about schemas or
| schema languages -- they are just implementation details best
| left under the hood. This is why in my own work, I started on the
| query end of the spectrum instead.
|
| This is why I built Trustfall, a query engine able to query any
| data source: DBs, APIs, files like PDF, CSV, or JSON, or any
| combination of those.
|
| GitHub: https://github.com/obi1kenobi/trustfall
|
| Playground showing the query "which GitHub/Twitter users comment
| on HackerNews stories about OpenAI?":
| https://play.predr.ag/hackernews#?f=1&q=IyBDcm9zcyBBUEkgcXVl...
| martypitt wrote:
| I agree that querying is where the real value is at, and
| Trustfall looks like an elegant approach.
|
| While Taxi is all about documenting & augmenting specs, Orbital
| is the query engine (which is a bit similar to Trustfall) that
| consumes those specs.
|
| Orbital's goal is to allow consumers to be able to query for
| data, without having to be aware of the specifics of the data
| sets / APIs / DBs, etc they're composing together.
|
| IMO GraphQL does a nice job on the query side of keeping
| consumers away from the wiring, but shifts the obligation to
| middleware resolvers.
|
| How data is wired together is ultimately an implementation
| detail, and one that changes. If consumers need to know about
| how stuff is connected, they're subject to breakages when those
| details change.
| gavinray wrote:
| > GraphQL does a nice job on the query side of keeping
| consumers away from the wiring, but shifts the obligation to
| middleware resolvers.
|
| I'm not sure that I understand how Orbital is different from
| tools that autogenerate GraphQL API's on top of data sources
| like databases and API's.
|
| From the site, it reads: > "Orbital uses your
| existing API specs and Database schemas - enriched with Taxi
| metadata to describe links. Orbital turns this into rich API
| and data catalog, letting you explore all your data, and how
| it connects."
|
| It sounds like the same concept, except using a new language
| instead of GraphQL?
|
| The schema language looks very similar to something AWS has
| called Smithy by the way:
|
| - https://aws.amazon.com/blogs/developer/introducing-smithy-
| id...
|
| - https://smithy.io/2.0/index.html
| martypitt wrote:
| Autogen tools do a nice job of creating GraphQL schemas
| from a single source.
|
| We're looking more at how to compose / stitch multiple
| sources into a single queryable API. (ie., Stitch data from
| a DB, some REST APIs, and a Kafka topic).
|
| In GraphQL, you need to write / maintain resolvers that
| handle the stitching for you - which means as upstream data
| sources change, resolvers need to be maintained too.
|
| Smithy is nice, and we'll probably add first-class support
| in Orbital for it at some point. Taxi was around before
| Smithy, so we're the OG :)
___________________________________________________________________
(page generated 2023-05-16 23:01 UTC)