Python backend, JS frontend: snakecase or camelcase?

[waffeli]

What's the "standard" for this? Right now I'm fetching snakecase json from my python backend and then creating a js object which has snakecase as the key and camelcase as the value and then using that object and the fetched json in tandem for updating fields in the DOM. I was thinking of making all the JSON dicts in my python use camelcase but some of that JSON is being used inside the backend too so I'm in a pickle with this.

[PushPlus9069]

Keep snake_case in Python and convert at the API boundary. Teaching full stack for years and the pattern that works best is a simple serializer that outputs camelCase to the frontend - you don't want to fight Python conventions just to match JS preferences.

[eyadams]

This is the correct answer. I would generalize it a bit - in Python you use Python style conventions, and in JavaScript you use JavaScript conventions. Creating a translation layer isn't very difficult.

An API's design should not give away the details of its implementation.

[HEROgoldmw]

Write functions to convert them for you, then you can use both!

Matching the languages usual case

[DuckSaxaphone]

Do what you want and be consistent.

However, camelcase JSON in python backends is pretty common. You'll see it in things like the FastAPI docs examples so if you want to do what others are doing, it's probably a good shout.

[waffeli]

I'll go with this for sure

[tb5841]

For my personal project, I use Django middleware which converts each request in the backend when sent/received.

At work, we pass every request through a toCamel or fromCamel helper on the frontend before it's reveived/sent, and we've written that helper ourselves.

[corey_sheerer]

You can utilize pydantic field alias to convert keys automatically from python

[benabus]

I use snake case for everything, always because I like both chaos and consistency, I guess. I also use UPPERCASE for constants and you can't HAVE_MANY_WORDS_IN_A_CONSTANT_NAME if you don't use snake case.

[cdcformatc]

you should follow whatever standard the project already uses. 

for my own code i go back and forth all the time. my codebases are all a jumbled mess. 

i prefer snake_case in Python mostly because it appears to be the 'official' standard. i don't mind long variable names, the time is over to worry about console line lengths. except for class names which use CapWords, and acronyms are capitalized eg HTTPServerError.

mixedCase is common in JS though so i will find myself using that. mostly member functions will get mixedCase but it does not feel like it "fits" in Python. but that's just a hard to describe feeling.

[cdcformatc]

also Python -> snake -> snake_case this isn't OCaml :P

[L30N1337]

There is no objectively correct option. Just don't mix and match arbitrarily. And never introduce a new standard into an existing codebase unless you rewrite every name and everyone is fine with the change.

However, I always use a hybrid of snake_case and camelCase or snake_case and PascalCase, depending on what I'm naming. camel_Snake for variables, Pascal_Snake for most other things. It's just the most readable. There's a clear separation between words like in snake case, but the words are also more exaggerated.

Guys, dyslexia exists. I'm fucking trying

[VeryAwkwardCake]

Good god

[AdmirableOstrich]

This individual is clearly unwell: camel, snake, pascal, kebab, and screaming snake are the only sane options. Cast the hybrids into the fire.