I think if you're defining a JSON API, that TypeScript is a natural fit since its types line up with with JSON - ie, number is the same in both and if you want something special like an integer with more precision, then you have to model it the same way in your JSON as your TypeScript interfaces (ie, a string or array). This makes TS good even for backends and frontends in other languages. You can also convert TS interfaces to JSON Schema for more interoperability.
I use `null` for that purpose, and it's been pretty reliable. What are the situations where that falls down?
So if you want to convert your TS interfaces to JSON Schema, you may need to provide additional constraints via JSDoc and use a generator that understands those annotations. But your TS interfaces cannot express those constraints directly.
There are a number other related complications surrounding these more expressive schema definitions - like building types from them and interacting with them at runtime.
I'll "just" use the type system built into my programming language until the pain of supporting multiple languages is more expensive than installing JSONSchema tooling and messing with code generation.
There’s a learning curve to these things. It always starts with type FunctionIWroteTodayArgs = …, which is useless and tells you nothing.
After a few iterations (this takes years) people gradually realize that the goal is to describe your domain and create types/interfaces/apis that are reusable and informative, not just a duplication of your code. You then get more useful types and things start really flying.
I guess what I’m saying is work on that with your team, not on ripping out tRPC.
If you’re talking about decoupled services, that’s about business domain composition more than type description. And those types benefit from a higher level description/reusability/transportability.
It’s similar to the problems you run into by writing the wrong kind of tests – the ones that essentially just duplicate your code instead of validating input/output at boundaries.
I don't see how declaring an http client server side and consuming it client-side can be a worse thing.
We use the same pattern of creating services that then every consumer can use (a web interface, a cli, etc) and the fact that those things never get to break is a massive improvement over anything I've seen in the past.
Make devs slower so they code smarter?
More friction is just that, it just frustrates devs it doesn't make them code better.
tRPC enables good teams to ship faster. Less friction means doing what the team was already going to do anyway, but faster.
IMO, at a minimum, you have your API layer model, your internal model, and your database model with a mapping layer at each boundary.
I rarely have problems when I structure it that way, but when working on applications that pass the same model from their API down to their database, or vice-versa, it's always full of the same types of problems that comes with tight coupling.
I think this is only really possible in a relatively small subset of programming languages, even among those with static typing. At a minimum it seems like it would require a type system that didn't allow optional properties (by default) and did distinguish between nullable and non-nullable types.
Unless I'm missing something. Would love to see some examples of this done right. Or at least examples of languages you've done this in.
there is a “REST Wrapper” project out there, but learning that was even needed was … fun
I don't mind it, we found other ways to test
Out of curiosity, how do you add a memcache to tRPC if you dont want to write directly to the prisma database
Would that help your team?
Happy to give you a demo if you reach out on Twitter dms or email (alex@trpc.io)