Всем привет.
Прошу помочь с теорией в клиент серверных приложениях, не web.
Сейчас есть самописная программа на python, что то типо ERP. Программа полностью запускается на клиенте + сервер MySQL. Хочу попробовать переписать её на клиент-сервер. Сервер будет получать данные из БД, подготавливать их и передавать клиенту, изменять данные, и например строить большие отчеты (сейчас это иногда может занять около часа).
Но не могу найти толковой информации, все что находится это web фреймворки, или простейшие клиент серверы на сокете.
Хочу понять модель работы, как передавать данные(большие таблицы, сложные структуры), как сервер понимает что ему нужно делать и так далее. Возможно есть готовые библиотеки для таких задач?
Я думал об этом, но это наверно излишне, и как обмениваться данными, через html, это вроде достаточно медленно, и если я правильно понимаю все запросы будут в виде server/new_order/user=1&client=2&...
Поподробнее например:
- Получить список заказов (большой и много данных)
- Завести новый заказ (или отредактировать) + позиции в заказе
- Рассчитать необходимое кол-во товара, материалов на выполнения заказа
- произвести списание товара со склада при отгрузке
- Построить отчет квартальный (большая куча цифр и запросов к БД)
- Вести склады методом FIFO, желательно периодически проверять склады по транзакциям
- рассчитать зарплату, сложив кучи операций по несколько копеек
- Так же есть ограничение прав для пользователей, что показывать, что можно нажимать
- И так далее в этом направлении
Александр Рублев, Звучит как веб сервис. Обмениваться данными можно и через json. Все запросы могут быть хоть в корень, всё зависит от того как они будут обрабатываться. Если честно, чтобы реализовать описанную функциональность тут как минимум основу хотя бы выучить надо...
javedimka, Этим я и пытаюсь заняться. Сама программа написана мной же, работает более менее, С сокетами дело имел на базовом уровне, Игрался немного с Django, более менее что то получалось.
Если web фреймворк, то это Django, или flask?
Александр Рублев, Так, погоди, а какая цель тогда у сервера? Почему захотелось переписать? Чтобы несколько людей могли программой пользоваться или что?
javedimka, Несколько людей и сейчас ей могут пользоваться. Переписываю по причине улучшения программы. Это первая программа, на ней я учился программировать, и конечно же там куча костылей, куча говнокода, да и с ростом кол-ва данных она начитает тормозить. Ну а так как я буду переписывать, хотелось бы сделать более грамотно, и поучиться новому.
В чем проблема?
В вебе более человеко понятные данные, в вашем случае можно выбрать любой RPC протокол что бы гонять данные. Плюс есть серьезная вещь в плюс отсутствие задержек и гарантированная связь в обе стороны.
Что же до отчетов, поставьте флажок что он начал готовиться и выводите спинер с обратным отсчетом.
Прочитайте что такое REST API и прекратите использовать дендрофекальный метод проектирования. Нужно правильно выбирать технологии под задачу.
Вы бы ещё свою шину данных под вашу ERP разработать попробовали. А что, подключаешься к GPIO на материнке и голыми битами по проводам, с контрольными суммами... Вам еще не кажется TCP избыточным? Может UDP? Вон кто-то выше Web RTC для ERP посоветовал. Давайте ещё как следует поелозим вдоль OSI.
javedimka, пардон, померещилось мне. Тут вы правы.
Если автор запускает на локалхосте - почему бы и не udp?
А вот тут нет. Если автор запускается на локалхосте, то ТЕМ БОЛЕЕ зачем ему UDP всё будет летать и так, а лишний слой протокола делать не придётся. Автору вообще проще всего использовать какой-нибудь микроферймворк вроде Flask. Вообще ничего лишнего писать не придётся.
А судя по тому какие и как вопросы задаёт автор, то я в недоумении что у него там за ERP и как он её написал.
Не, ну может эдакий маугли от разработки... нафигачил крутой GUI, умеет делать отчеты как-то, в архитектуре клиентского приложения не накосячил настолько, что можно легко прикрутить сетевой протокол и проект не вылезет за когнитивные способности автора.
UDP имеет смысл в каких-то играх, где нужно пересылать в реальном времени поток событий и можно пренебречь негарантированной доставкой пакетов или несохранением очередности. Или в каких-то интерактивных медиа-коммуникациях можно UDP использовать. Транслировать там что-нибудь быстро... Но делать ERP на голом TCP и десктопном приложении в 21 веке это всё равно, что паять игровой компьютер иа транзисторах самому. Наверно можно попробовать повторить на кухне тех-процесс и чипы запекать в духовке, но... это неоправданный расход времени и, что самое главное, сложности. Сложность - это основной ресурс в любой системе. Если она превысит пороговый уровень когнитивных способностей понимания человека, то проект погибнет под собственным весом. Для уменьшения сложности придумали всякие фреймворки, которые прячут сложность и рутину от программиста.
Сергей Паньков, Я где то настаивал на UDP? Или я где то говорил что я против фреймворков? Мне кажется я сюда и пришел с вопросом посоветовать решения для моей задачи? Или теперь у нас тостер только для гениев и опытных разработчиков стал?
Не понимаю что вы так взъелись. Только супер опытные программисты могут делать полезное ПО? Или это плохо, что я для своего предприятия пишу свое ПО, которое учитывает все наши задачи? Обычный GUI типо MDI окна с таблицами и формами. Моя программа удовлетворяет потребностям производства, считает ЗП, Склады, продукцию, себестоимость и так далее, Возможно я не правильно понимаю ERP, возможно правильнее сказать программа учета предприятия, но это работает, и я хочу сделать еще лучше, это тоже плохо? Или мы должны обязательно пойти отдать сотни тысяч на разработку?
Александр Рублев, да не обращайте внимания, я просто злобный мерзкий тип.
Вы, видимо, большой молодец, раз делаете работающий полезный продукт. Я просто некорректно и довольно хамски попытался объяснить несуразность и неэффективность применяемых и рассматриваемых вами технологий.
Это моё личное нескромное мнение. Не принимайте близко к сердцу.
Сергей Паньков, Спасибо за понимание (Если это не сарказм)
Я вот теперь думаю REST API как вы посоветовали или grpc который посоветовали выше, вроде и то и то имеет право на жизнь, и то и то вроде должно работать) Может подскажете в этом вопросе?
Александр Рублев, в данном случае не сарказм.
Мой вам совет, посмотрите в сторону Flask. REST API на нём - это максимально быстрый (в плане разработки) и не затратный (тоже в плане разработки и в плане когнитивных усилий) способ сделать бэкенд.
Может быть в какой-то момент вы найдёте фронтендера или сами решите попробовать себя на этом поприще.
