3 ms·

I’m sad to see that Taxi doesn’t support union/sum types! We make use of them quite heavily at Notion - our “block” model is a union of 60 subtypes - so it’s a

by jitl 4y ago

I’m sad to see that Taxi doesn’t support union/sum types! We make use of them quite heavily at Notion - our “block” model is a union of 60 subtypes - so it’s a make or break feature for any semantic language we’d use internally. For Kotlin, taxi could support this by generating sealed (data) class. GraphQL’s schema language seems similar in some respects, and supports union types but not generics. I’m also curious about how teams or systems onboard to Taxi. There’s a lot of advice about “models shouldn’t be shared between teams” and such. How would you suggest an engineering org go from a shared set of models defined in some other language today, to model-per-team defined in Taxi? I’m a bit confused about to what degree models should encode some existing types in an implementation, or if models should be idealistic, and the implementation will need to do a lot of data munging to produce a structure that matches the model. Finally, how should teams think about computed properties / expressions? If models describe the input or output of an API my team owns, wouldn’t our API compute these properties internally? Why expose a possibly-incorrect expression to compute it?

martypitt 4y ago
Hey. There's a few things here, and I'd be keen to chat about them in more detail - I'm marty at vyne dot co, or often on our slack - if you're keen to dive into anything further. > I’m sad to see that Taxi doesn’t support union/sum types! These are in progress right now. I'm not sure how well it fits your usecase, so it'd be interesting to chat. > For Kotlin, taxi could support this by generating sealed (data) class. That's a nice idea. We have a kotlin generator for taxi, but I hadn't gotten to how we would handle the union types. I feel like you just saved us a few iterations! :) > I’m also curious about how teams or systems onboard to Taxi. There’s a lot of advice about “models shouldn’t be shared between teams” and such. What we're advocating against here is a common domain model - where everyone in the org is expected to model a Customer in exactly the same way - this leads to everything being optional. In terms of onboarding, there's normally a few components: * A shared set of types (no models), describing in a taxi project, which lives in a git repo somewhere * Teams start describing their APIs using those types - either by publishing a Taxi model directly, or (more commonly), embedding the taxi types in their Swagger / Proto etc. * Teams then start querying using TaxiQL and a query server (like Vyne) to fetch data from across those APIs. This keeps the consumers decoupled from the producer schemas. > Finally, how should teams think about computed properties / expressions? [..] wouldn’t our API compute these properties internally? Yeah, it's uncommon for a producer contract to include a computed property - though we have seen teams do this against things like CSV models. It's more common for consumers to use these for declaring the computed result they want for a field in a query, and let the query service handle the computation. This allows either ad-hoc computation (defined in a field), or shared common expressions, defined as an expression type.

by jitl 4y ago

martypitt 4y ago

Hey. There's a few things here, and I'd be keen to chat about them in more detail - I'm marty at vyne dot co, or often on our slack - if you're keen to dive into anything further. > I’m sad to see that Taxi doesn’t support union/sum types! These are in progress right now. I'm not sure how well it fits your usecase, so it'd be interesting to chat. > For Kotlin, taxi could support this by generating sealed (data) class. That's a nice idea. We have a kotlin generator for taxi, but I hadn't gotten to how we would handle the union types. I feel like you just saved us a few iterations! :) > I’m also curious about how teams or systems onboard to Taxi. There’s a lot of advice about “models shouldn’t be shared between teams” and such. What we're advocating against here is a common domain model - where everyone in the org is expected to model a Customer in exactly the same way - this leads to everything being optional. In terms of onboarding, there's normally a few components: * A shared set of types (no models), describing in a taxi project, which lives in a git repo somewhere * Teams start describing their APIs using those types - either by publishing a Taxi model directly, or (more commonly), embedding the taxi types in their Swagger / Proto etc. * Teams then start querying using TaxiQL and a query server (like Vyne) to fetch data from across those APIs. This keeps the consumers decoupled from the producer schemas. > Finally, how should teams think about computed properties / expressions? [..] wouldn’t our API compute these properties internally? Yeah, it's uncommon for a producer contract to include a computed property - though we have seen teams do this against things like CSV models. It's more common for consumers to use these for declaring the computed result they want for a field in a query, and let the query service handle the computation. This allows either ad-hoc computation (defined in a field), or shared common expressions, defined as an expression type.