Choice of programming language is often best guided by the context in which it is going to run, and the availability of examples which could be adapted from accomplishing the same basic task for slightly different data, to accomplishing the task for needed data.
The javascript decoders running within TTN have historically had some reliability problems, but they the one place you can insert something without having to create a new sort of context in which it can run.
To use something else (python, java, even javascript running under node) you’d need to get or push the data from TTN into a place where the custom software runs, and from there push into influx, rather than do so directly. For example you might get the data by having a task on a server subscribe to the MQTT feed, decode it, then push records of parsed fields into influx.
While you could store raw still-concatenated payloads in influx, you won’t really get the benefit of a time series database with an arbitrary chunk of bytes, but only if you’ve already broken the data items into individual fields whose change over time is distinctly visible before you insert them.
You also want to make sure you’re capturing metadata such as timestamp and frame count; spreading factor and gateway/RSSI pairs can be useful too to understand changes in coverage and reliability over time.