[WIP] Full Stack Type Safety #58
Conversation
| } | ||
| ``` | ||
|
|
||
| The general workflow for using this approach would be to add a step to the backend build process which generates a type declaration file as shown above. There are existing tools which provide this functionality, I've considered evaluating them out of scope for the time being. The generated file can be added to the frontend project scope and the type definitions can be used accordingly where needed. This change can be adopted gradually over time. |
There was a problem hiding this comment.
I am not against the overall idea, but think it's critical to define how this type declaration file can be generated from the backend code.
Without that piece, I guess the only possibility would be to create it manually. But in my understanding, that would only move the problem one step away, from "backend to frontend" type coherence to "backend to declararation-file" type coherence - correct?
There was a problem hiding this comment.
That is correct, yes. Without automated tooling, I don't think this proposal is reasonable. I haven't had the chance to see this approach in action on a Java project before so I don't know what tools may be applicable or realistically pluggable with our architecture. At my previous job we had a good run using NSwag on a .NET Core project, the flow there was that our backend project had Swagger tacked on and NSwag used the JSON output by Swagger to generate Typescript types.
NSwag did have one major drawback in that the generated type names were not consistently unique. You could have entities with the same name in different business scopes, a-la both named Entity, mapped to names such as Entity1 and Entity2 in the output but when Entity1 was removed in a refactor, Entity2 would then become just Entity. That was a big pain point for us, I haven't checked whether they've found a fix for it since.
There was a problem hiding this comment.
The feasibility of this project highly depends on the details of implementation. Personally, I'd prefer the manual annotations, but I'm not entirely sure if it's worth all the extra effort on build, CI and especially dev environments.
OTOH, honestly, I don't see this topic as a major problem because:
- Backend DTOs are mostly simple objects intended exclusively for a single endpoint and therefore rarely get modified. We almost always use exclusive Java objects for API endpoints.
- Since they're tightly coupled with frontend counterparts, whenever they are modified, it's either because of a frontend change, or they anyway get updated with the frontend counterparts. It's unlikely that the other part would be forgotten.
- Any regression that might be caused by a type change would be easy to catch with the simplest of tests (I believe we must spend the most effort on frontend unit tests and improving type coverage in TS)
|
I am starting something similar at the moment for Cobbler. The reasoning is the same as @Etheryte described. With XML-RPC there is however no tooling that is "nice" available IMHO. OpenAPI is refuses to support any kind of RPC first-party, it is not impossible to map all actions to a single route, however atm it is manual tedious work. The community did not pick up the work to develop the tooling according to my research so far. I am in favour of creating an OpenAPI specification because I would like to be driven by a specification and not by the implementation. Even if that means more work. |
This is a rough draft of an idea that's been floating around in my mind for quite a long while. Hoping to get some feedback without sinking considerable effort into this upfront.