Remote types are neat but naive #4895
devinrhode2
started this conversation in
Ideas
Replies: 1 comment
-
|
Remote types give you a sense of security during initial development, but if you are an avid typescript user, you are very comfortable changing types as you refactor. Of course we can easily fix the types on the other side of the mfe contract. But if this pattern goes unchecked, you can easily end up with a distributed monolith, and can then start losing out on your ability to deploy independently. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
I thought the remote types feature was quite cool, we can retain some semblance of monorepo style development across repos. However.. It doesn't make sense at a fundamental level:
For me, I wish our team never adopted this remote types idea.
I think generally a team should just use zod schemas at the boundaries of their type system.
If those boundaries are changing a lot and have a lot to character (generated .d.ts is more than 1 page), then you have a different problem, you might want to use npm packages if the code you are sharing is tiny.
It must be emphasized, in a system of independently deployed parts, it's quite unlikely we'll see anything better than zod-like errors. Zod errors are not like npm peer dep errors. Zod of course has no concept of semver. With zod, we get a full dynamic attempt to connect two disparate ends of a contract. And if there's a mismatch, we get a detailed error saying what we got and what we expected. This is far better than an npm semver restriction.
Therefore, although zod errors can be a little cryptic and hard, they are ideal when you have independently deployed units.
Solutioning
I would propose Zephyr Team actually work on this internally, because coordinating these separately deployed components is literally what their product is designed to do. Maybe The mfe zod schemas/contracts could be exposed in some way, some tool could resolve imported sub-schemas. Then you need type information for "the other side of the contract", and lastly you compare the two.
Beta Was this translation helpful? Give feedback.
All reactions