In our organization. We run numerous big data pipelines, where data is transmitted, stored, and processed using variety of technologies. JSON is the goto format for this and camel casing doesn't work well with a lot of big data query engines (and solutions it to work with camel casing is nasty or way too hacky ), so the natural option is to use snake casing. With that out of the picture, the next problem is that a lot of big data frameworks are JVM based, in those scenarios we use Jackson's Object mapper naming feature to convert it back to internal POJOs where camel casing is followed.
In our organization. We run numerous big data pipelines, where data is transmitted, stored, and processed using variety of technologies. JSON is the goto format for this and camel casing doesn't work well with a lot of big data query engines (and solutions it to work with camel casing is nasty or way too hacky ), so the natural option is to use snake casing. With that out of the picture, the next problem is that a lot of big data frameworks are JVM based, in those scenarios we use Jackson's Object mapper naming feature to convert it back to internal POJOs where camel casing is followed.
Jackson's feature:
objectMapper.setPropertyNamingStrategy(PropertyNamingStrategy.SNAKE_CASE);
Thanks for the detailed information. 🙌
So in your case, to choose the snake case was more of a pragmatic approach. The matter of which case is easier to work with.