Руслан Янбердин: почитайте исходный код node.js, попробуйте внесит в него изменения, напишите один два больших и качественных по содержанию проекта на нём и тогда сами поймёте что он прилично кривой.
Владимир Грабко: про то что вы пишите и пишите много я в курсе, вы выразились так как буд-то у вас данные по другим компаниям или группам разработчиков. Что сильно разное.
Артем Кисленко: вот вы и ответили на вопрос. Если и поддерживать dual-stack то между сервисами на разных языках делать соединения rpс или делать внутреннее api.
Я видел как люди большие проекты переписывают на Go путём вынесения тяжелых кусков в Go и со временем вообще уходят от питона.
Что за проекты?
нет там никаких тонкостей, чтобы по 5 лет учить.
Если вы можете написать на языке всё что угодно, включая всё что уже написано на текущий момент и сделать это без шпаргалок то да, вы, видимо узнали все тонкости... за пару лет уложитесь? А то тут разработчиков сложно хороших найти, а отличных и подавно.
Если суть такая же как у socket.io то там особенность в том что в зависимости от клиента может использоваться не только Websockets но и long pooling и передача через iframe...
Symphony: только хотелось бы поменьше прописывать кучу точек и поменьше полагаться на магический animate... плюс SVG не везде удобно встраивать, иной раз хочется чистый DOM. Но как вариант да, можно подумать о том что бы всю страницу сделать "одностраничником" на SVG.
Александр Катков: это не оправдывает вашу грубость. Учитесь формулировать мысли, это так же поможет вам не только объяснить в чём ваша проблема но и поможет делать более качественный код.
Начнём с того что вопрос изначально был про CMS, а описание ничего от CMS не содержит... О том что это Content management system пользователи узнали только потому что речь шла о роутинге, $_GET, $_POST и прочем таком.
Александр Катков: люди просто не поняли в чём же ваша просьба о помощи потому что так же увидели не стыковки в вашем тексте. Это нормально, обижаться на это не стоит, обзывать людей флудерами только потому что они обратили внимание на ваш вопрос тоже не стоит - в другой раз могут и пройти мимо.
Когда освоите попробуйте парсить внешний источник без предварительного сохранения файла на диск. В случае сетевых ошибок:
- докачивать файл с момента получения ошибки - использовать http заголовок для чанков
- при докачки проверять не обновился ли файл - опять через http заголовки
- если файл обновился - принимать решение что парсить нужно с начала
Google: поточный парсинг php
- не перезапускать скрипт
- если перезапускать то:
-- контролировать что файл не обновился
-- запоминать смещение в файле до которого уже распарсили
Обычно поточный парсер предполагает что:
- вы читаете файл с начала до конца
- по мере нахождения в файле объектов создаёте их в памяти, делаете над ними операции, а потом удаляете из памяти и переходите к следующему найденному объекту
- объекты ищутся по начальному токену (например ), потом объект собирается по заверщающий токен (например )
Вы тут подразумеваете что A - это "статичный объект" в общем адресном пространстве. Вы так и себя запутаете и программу в конечном итоге.
Суть MVC в том что бы разбивать код на логические составляющие: Modul - в идиологии Golang это могут быть пакеты которые отвечают за работу с конкретными данными, например отдельно пакет user, post, message и прочие, при этом каждый пакет имеет свой интерфейс наружу - для получения пользователей, для сохранения пользователей, для создания пользователей и так далее View - это по сути шаблонизатор и обвязка вокруг него, например если у вас есть пакет tmpl то у него вероятно есть метод view(address string, data interface{}), вызвали в контроллере tmpl.view("index.html", data) где нужно и получили готовую отрендеренную страницу Controller - это по сути стопка функций у которых на вход http.Response, *http.Request и может быть ещё что-то специализированного, вроде контекста где указатель на текущего пользователя и какие-то дополнительные ресурсы, по сути типичные хандлеры для http
А то что было описано в вопросе - это не напоминает MVC никак.