Aragorn

Нет книг, которые охватывают все эти темы. Придётся отдельно прочитать Лутца для изучения языка, например Грабера для изучения SQL, руководство Django для изучения Django и т.д. и т.п. Причём всё это будет на уровень джуна, так как мидловый грейд - это не знания, а годы коммерческого опыта командной разработки.

Вы немного путаете причины и следствия.
Если ML и аналитику делают чаще всего н апитоне, это не значит, что на питоне делают чаще всего аналитику и ML. Просто для аналитики и ML в питоне очень много "батареек", он в этом направлении лидер. Но основное применение питона - это бэкенд. Джанго действительно очень популярна, и его только недавно стал перегонять FastAPI соблазняя своей асинхронностью.
Прелесть и преимущество Джанги в его самодостаточности для многих направлений применения. Там и довольно элегантный ORM в коробке, и шаблонизатор, и, что часто очень важно, простя в использовании и мощная админка с системой атворизации и управления правами. Практически с голой джангой и за пол часика можно быстро набросать модель данных и развернуть MVP, причем совсем не придётся тратить время ни на авторизацию, ни на организацию всяких там систем миграций, таск-менеджмента, модульного согласования разных фичей и т.д..
А если учесть, что гитхаб ломится от готовых блогов, магазинов, чатов, виджетов, систем работы с комментариями в виде приложений для джанго, а эти приложения егко собираются в один проект и не толкаются друг с другом локтями при этом, то тут вполне можно понять почему Джанго так популярен.
Питон в целом и Джанго в частности дают скорость разработки, которой позавидуют любые другие языки и фреймворки. При этом язык довольно свежий, современный и удобный.

Однако меня смущает ваша постановка вопроса. Такое ощущение, что вы себе стек подбираете по озвученным критериям. Эдак могу посоветовать идти в перловики. На перле тонны легаси, в котором сейчас хрен кто ладу даёт, все бегут на что-то покомфортнее, а зарплаты у перловиков из-за вакуума на рынке не маленькая. Ну там, где это вижу я. Да, будущего у языка нет, но здесь и сейчас можно постричь бабла и подоминировать на своей нещаменимости=).
Java - это жирный энтерпрайз, там всегда были и будут деньги. Полагаю крупные компании не сильно боятся обучать себе джунов, потому что эти джуны не улизнут в стартапы и будут залочены на корпоративный сегмент.
Почему меня сутил ваш подход. Дело в том, что разных направлений развития много и в каждом можно преуспеть, но преуспеть в любом направлении сложнее, если вы выбрали его не по "зову сердца", а по меркантильным соображениям и требованиям рынка. У вас может просто не хватить мотивации, чтобы добиться нужного уровня профессионализма для востребованности в выбранном сегменте.

Потому что вы два раза пытаетесь зачем-то спарсить http-ответ как JSON. Очевидно в Json один ответ.
Вы ришли в магазин, запросили коробку конфет, вскрыли, получили список конфет и выкинули вместе с коробкой и конфетами.
Потом снова делаете двидение руками, будто берете с прилавка коробку конфет (но ее там нет же, вы только одну запросили у продавца), лезете в воображаемую коробку рукой и не находите там конфету.
Странно, правда?

Если бы вы не нарушалиправило и не постили код в виде скриншотов, то я бы вам процитировал ваши ошибки и, наверно даже, написал бы как равильно делать.
Но вы нарушаете правила.

Почему csv iterator не записывает все, хотя должен?

Нет, не должен. Итератор не должен ничего записывать, он интератор. Итератор итерирует. Всё.

Вот вы пришли с вопросом, но по какой-то причине не включили в него самое важное, то по чему можно определить причину такого повеения вашей программы.

Во-первых, вы не привели примера данных. Если что-то идёт не так, как ожидается, ВСЕГДА нужно приводить два набора данных: тот, который работает как ожидается и тот, который как ожидается не работает. При этом не обязательно приводить полные наборы данных, ведь их может оказаться очень много. Всегда нужно стараться упростить непонятную ситуацию максимально, и в какой-то момен она станет понятной. Ну, то есть, возможных причин проблемы в рассмотрении станет достаточно мало, чтобы понять какая из них действительна.
В данном случае нужно было убирать из CSV всё лишнее до тех пор, пока проблема сохраняется. Если убирать уже нечего, то останутся только проблемные записи и, возможно, посмотрев на них, вы сразу всё поймёте. Или поймёт тот, к кому вы пришли с вопросом.

query = """variables_loaded[variables_iterator]['0']""" ##, так далее

Во-вторых, у вас какой-то совершенно невалидный SQL-запрос. Он бессмысленный и неправильный. Вот это буквально текст, который запросом не является. Он даже не меняется от итерации к итерации, понимаете? Нам тут не ясно что вы имели в виду под "так далее", нам тут не ясно понимаете вы что такое SQL и что вот та строка им не является.

При всех ваших ошибках в постановке вопроса нам тут уже не ясно, может быть у вас вообще нет работающего кода, который что-то записывет из CSV в БД, а то, что вы думаете он, якобы, запсывает, уже и так есть в БД, а вы просто этого не понимаете! Ну как не понимаете, что проблема может быть в SQL-запросе, поэтому его не приводите, как не понимаете, что проблема может быть в индексах и структуре БД, поэтому не приводите её структуры, как не понимаете, что проблема может быть в данных (они могут повторяься в разных строках CSV), а вы и не приводите все данные, и не говорите, что убедились, что они не повторяются!

execute_query(connection, query)

В-третьих, вы оставляете за скобками код выполнения SQL-запроса. Мы не знаем что это за код, может быть там вы тупо try-except'ом задавили все возможные ошибки и сами, фактически, отказались от того, чтобы БД вам объяснила в чем проблема. Может быть это вообе пустая функция внутри, или она неправильно обернута каким-нибудь декоратором, который ей не дает работать, а вы просто видите в БД одни и те же данные, и думаете. что они каждый раз туда заливаются вновь вот этим неработающим вообще кодом.

Как нам судить обо всём этом букете гипотетических пробелм, если вы старательно все улики замели под ковер? Для чего вы это сделали?

Вам нужно многое понять и изучить прежде чем такая задача станет вам под силу. Судя по постановке вопроса вы очень далеки пока что от понимания основ алгоритмизации и структур данных.
Конечно можно ставить любое уникальное значение любому объекту. Структура данных, которая это позволяет, называется map, а в питоне её реализует тип dict - это словарь, который ставит в соответствие любой объект любому уникальному другому объекту.
Я уверен моего объяснения будет не достаточно вам. Почитайте любую книжку по питону с нуля, например, Марк Лутц пишет приемлемые.
Ещё вам определенно понадобится какая-то БД, например sqlite, или что-то посерьёзнее, например postgres. Базы жанных - это тоже отдельный целый мир, но вам не нужно вних сильно углубляться, однако, одного вопроса, да и вообще вопросов будет недостаточно для нормального понимания.

Я вам рекомендовал бы обратиться к фрилансерам за таким ботом, либо, если самому интересно, то читайте книжку по питону с нуля и там вам всё будет объяснено, что нужно для простого бота с вашей функциональностью.

Дело в том, что пока ваши устройства в одной подсети (им выдал адреса один DHCP сервер, это обычно ваш роутер), вы, указав локальный IP другого устройства в сокете, можете создать соединение.
Но если устройства в разных локальных сетях, между которыми не настоен никакой роутинг, то устройства не смогут видеть друг друга. Их адреса будут в разных адресных пространствах.
Это как звонить внутри отеля по внутреннему номеру телефона. Если один из абонентов окажется в другом отеле, то, даже зная его внутренний номер, вы из первого отеля не дозвонитесь ему напрямую по короткому номеру. Придётся пользоваться шлюзом. Вот шлюз - это NAT.
Тут дальше аналогия уже поплывёт, если ещё глубже пытаться её применять.
Прочитайте что такое NAT, что такое белый IP, динамический и статический IP, что такое port-forwarding, сетевая модель OSI, что такое маска подсети и как устроен IP-адрес, как происходит маршрутизация.
Это слишком много инфы, чтобы рассказывать вам об этом в ответе на один вопрос. Вам нужно изучать это самостоятельно.