3 ms·

In one case we had a setup close to that. But the case I'm talking about is when you'd have something too complex to encode simply in a standard type system (e

In one case we had a setup close to that. But the case I'm talking about is when you'd have something too complex to encode simply in a standard type system (even with dependent types...). So you have some subtle relationships between different fields, or some specific subtree might be a forbidden substructure, etc. Reimplementing algorithms might be necessary on the frontend for interactive purposes. For most standard use-cases I agree you can have this well-define separations between backend and frontend.

chatmasta 4y ago
Yeah, I think I know what you mean, and we have a case of this in our search system where Facets are dynamically defined, and available facets are sent in each response so that subsequent requests can use them in their payload. Ironically enough that is the one backend service that is written in TypeScript, and does share some code with its frontend implementation for just the reason you describe. We also have plugins for importing data where the parameters are dynamically defined with JSONSchema, and we had to do a whole bunch of work to make validation and form rendering work properly on the frontend, while also duplicating it in Python, but luckily we can mostly fall back on standard JSONSchema libraries for that (we also use superstruct on the frontend). We have to rely on getting it "mostly right" in the frontend and then trusting the backend to send back an error message on failed validation (and then we have the problem of rendering that error message in the right place). Generally speaking this still bites us with any GraphQL resolver that has a field returning JSON for whatever reason. The major aspect of code sharing we're still missing is validation of that data between front and back end, and I can see how keeping all your logic in Python would help with this if you're both rendering and validating forms from the same Python code. Of course you can get the same benefit from writing your backend code in JS and sharing that, and I guess that's one of the downsides of our approach, since we lose out on both options.

chatmasta 4y ago

Yeah, I think I know what you mean, and we have a case of this in our search system where Facets are dynamically defined, and available facets are sent in each response so that subsequent requests can use them in their payload. Ironically enough that is the one backend service that is written in TypeScript, and does share some code with its frontend implementation for just the reason you describe. We also have plugins for importing data where the parameters are dynamically defined with JSONSchema, and we had to do a whole bunch of work to make validation and form rendering work properly on the frontend, while also duplicating it in Python, but luckily we can mostly fall back on standard JSONSchema libraries for that (we also use superstruct on the frontend). We have to rely on getting it "mostly right" in the frontend and then trusting the backend to send back an error message on failed validation (and then we have the problem of rendering that error message in the right place). Generally speaking this still bites us with any GraphQL resolver that has a field returning JSON for whatever reason. The major aspect of code sharing we're still missing is validation of that data between front and back end, and I can see how keeping all your logic in Python would help with this if you're both rendering and validating forms from the same Python code. Of course you can get the same benefit from writing your backend code in JS and sharing that, and I guess that's one of the downsides of our approach, since we lose out on both options.