8 ms·

I agree with you, I didn’t expect the amount of negative comments. Used in the past and it was a great tool to “avoid representing invalid states” and also as d

by solids 5y ago

I agree with you, I didn’t expect the amount of negative comments. Used in the past and it was a great tool to “avoid representing invalid states” and also as documentation to share between teams.

chrisjc 5y ago
> I didn’t expect the amount of negative comments I did! It's been made clear time and time again on HN that "everyone" HATES XML and anything to do with it... especially XSD, WSDL, etc! I really don't see any difference between XML and JSON except the semantics (I lie, I see a lot of reasons why XML is more powerful). But I do get why people prefer JSON over XML for visual reasons alone. Since they're very similar logically/structurally, it only makes sense that the same things that are possible with XML are possible with JSON. And here we are, discussing JSON schemas! So is it really that they hate XML and love JSON for any other reason besides the visual ones? If not, what is it that they hate? I think it has to do with the responsibility and effort that goes into creating a contract, the "schema". All the anxiety and headbanging that goes into setting up all the meetings and discussions. All the convincing that happens over and over again just to move forward. All of the back-and-forth that goes into whether it's this type or that bc the requirements are ambiguous to begin with and now it's the developer's responsibility. "I could just throw this API together in a day if it wasn't for all these useless meetings. Why do I have to wait for Bob to update the schema when I can just cast this field to a boolean in my code?". "I don't want to have to deal with validation exceptions at runtime, just fix your damn code and read the wiki I put together." etc. (I do understand that not all APIs, data exchange files, tightly coupled project, etc... need schemas) In my experience, while these schema-less approaches lead to projects being leaner and completed sooner, the price is payed continuously there after. Something changes on the server-side, some edge case appears on the UI several weeks after release to prod. Enhance the structure, breaks ETLs. And so on. A perceptual state of keeping everything in tranquility emerges.
- spookthesunset 5y ago
  > Something changes on the server-side, some edge case appears on the UI several weeks after release to prod. Schemas don’t fix this problem. The reason the thing probably broke is the change wasn’t backwards compatible with the clients calling the service. No schema will fix that. If the client hasn’t been updated to consume the breaking change it is gonna break, period. Schemas don’t get you out of handling breaking changes to your API. That being said they might expose an unintentional breaking change in automated testing of the server. Which, I suppose, is a good thing. I mean using a standard tool for schema validation in testing… yeah I can get on board with that. But no schema validation will ever be able to “fix” an intentional breaking change to an API. In conclusion, writing this comment now has me kinda on board with schema validation for automated testing. It probably won’t catch all forms of unintentional breaking changes but it could catch some.
  - chrisjc 5y ago
    Just to clarify, I wasn't suggesting that schema validation will ever be able to "fix" a breaking change to an API, intentional or not. And I'm not suggesting that you release new versions of server-side APIs without doing the same on the client-side. (although I understand there are a whole lot of deployments where that's the norm) What I'm suggesting is that if there are changes made on the server-side that introduce breaking changes to the schema, should be easily picked up at build time (test phase, maybe even compilation). Of course there are going to be exceptions to this when perhaps using a language's truthiness, or code that converts everything in the payload to a string... But I', pretty sure for 99% of the cases, esp if you use the schema and tools based on schema (code gen) you'll end up in a better place.
- stueynz 5y ago
  Amen brother (or sister)

by solids 5y ago

chrisjc 5y ago

> I didn’t expect the amount of negative comments I did! It's been made clear time and time again on HN that "everyone" HATES XML and anything to do with it... especially XSD, WSDL, etc! I really don't see any difference between XML and JSON except the semantics (I lie, I see a lot of reasons why XML is more powerful). But I do get why people prefer JSON over XML for visual reasons alone. Since they're very similar logically/structurally, it only makes sense that the same things that are possible with XML are possible with JSON. And here we are, discussing JSON schemas! So is it really that they hate XML and love JSON for any other reason besides the visual ones? If not, what is it that they hate? I think it has to do with the responsibility and effort that goes into creating a contract, the "schema". All the anxiety and headbanging that goes into setting up all the meetings and discussions. All the convincing that happens over and over again just to move forward. All of the back-and-forth that goes into whether it's this type or that bc the requirements are ambiguous to begin with and now it's the developer's responsibility. "I could just throw this API together in a day if it wasn't for all these useless meetings. Why do I have to wait for Bob to update the schema when I can just cast this field to a boolean in my code?". "I don't want to have to deal with validation exceptions at runtime, just fix your damn code and read the wiki I put together." etc. (I do understand that not all APIs, data exchange files, tightly coupled project, etc... need schemas) In my experience, while these schema-less approaches lead to projects being leaner and completed sooner, the price is payed continuously there after. Something changes on the server-side, some edge case appears on the UI several weeks after release to prod. Enhance the structure, breaks ETLs. And so on. A perceptual state of keeping everything in tranquility emerges.

spookthesunset 5y ago
> Something changes on the server-side, some edge case appears on the UI several weeks after release to prod. Schemas don’t fix this problem. The reason the thing probably broke is the change wasn’t backwards compatible with the clients calling the service. No schema will fix that. If the client hasn’t been updated to consume the breaking change it is gonna break, period. Schemas don’t get you out of handling breaking changes to your API. That being said they might expose an unintentional breaking change in automated testing of the server. Which, I suppose, is a good thing. I mean using a standard tool for schema validation in testing… yeah I can get on board with that. But no schema validation will ever be able to “fix” an intentional breaking change to an API. In conclusion, writing this comment now has me kinda on board with schema validation for automated testing. It probably won’t catch all forms of unintentional breaking changes but it could catch some.
- chrisjc 5y ago
  Just to clarify, I wasn't suggesting that schema validation will ever be able to "fix" a breaking change to an API, intentional or not. And I'm not suggesting that you release new versions of server-side APIs without doing the same on the client-side. (although I understand there are a whole lot of deployments where that's the norm) What I'm suggesting is that if there are changes made on the server-side that introduce breaking changes to the schema, should be easily picked up at build time (test phase, maybe even compilation). Of course there are going to be exceptions to this when perhaps using a language's truthiness, or code that converts everything in the payload to a string... But I', pretty sure for 99% of the cases, esp if you use the schema and tools based on schema (code gen) you'll end up in a better place.
stueynz 5y ago
Amen brother (or sister)