Why we created Taxi, and why we felt the need for another schema language
1–10 of 28 posts
Re: Why we created Taxi, and why we felt the need for another schema language
#2I'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...
Re: Why we created Taxi, and why we felt the need for another schema language
#3Couldn’t quickly find it, but does it support enums/sum types?
Re: Why we created Taxi, and why we felt the need for another schema language
#4The 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#?
Re: Why we created Taxi, and why we felt the need for another schema language
#5Couldn’t quickly find it, but does it support enums/sum types?
Enums, yep: https://taxilang.org/language-reference/types-and-models/#en...
Sum types, no, not yet.
Re: Why we created Taxi, and why we felt the need for another schema language
#6i 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
Re: Why we created Taxi, and why we felt the need for another schema language
#7i 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
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.
Re: Why we created Taxi, and why we felt the need for another schema language
#8I think there was a related thread about this in recent weeks but I can't find it. Anyone?
Re: Why we created Taxi, and why we felt the need for another schema language
#9I'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…
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.
Re: Why we created Taxi, and why we felt the need for another schema language
#10I think there was a related thread about this in recent weeks but I can't find it. Anyone?
Taxi was discussed 12 months ago here: