про удаления согласен, про json не совсем согласен. Наша система бронирования и система билетов показала что далеко не всегда люди делают заказы на себя
Давайте теперь по делу и займемся немного реверс инжинирингом. Вы делаете калькуляцию счетчика баннера. Более того, вы в коде рассчитываете значение и фиксируете его, не рассчитывая на конкурирующие запросы, что означает что у вас статистика не верная.
Совет #1: упрощайте. вы можете свести все к одному обновлению таблицы:
update tbl_banner set views = views + 1 where id in (1,2,3,4,5);
и вам не придется предварительно выбирать эту информацию.
Совет #2: Выкиньте это все к чертям. Поясняю почему на пальцах.
У вас есть просмотры баннеров - это одна сущность (какой баннер, в какой момент времени, на какой странице, какой userAgent, язык, IP ....)
Суточная статистика это другая сущность, как и недельная, месячная и вообще.
Статистика просмотра баннера это вообще отдельный разговор - цифра бессмысленная по тому как не несет за собой ничего кроме суммарной цифры за все периоды (но может вам очень надо).
Подобные цифры калькулируются как минимум периодически по крону. В идеале подключить очереди, а вообще для скорости можно, допустим, использовать clickhouse.
Совет #3. Эт оне просмотры баннеров, а рендеринг страницы с этим баннером. Подключите яндекс.метрику и отправляйте с клиента события. и никаких проблем с этой статистикой у вас не будет
Роман Мирр, хорошее веб-приложение за собой имеет стройную низкосвязанную сервисную архитектуру, которую можно свободно масштабировать в зависимости от потребностей: как вертикально так и горизонтально. Такие вещи как RoR, Yii2, Symfony, Django и вот это вот все ведет к появлению монолитных систем и к высокой стоимости поддержки, низкой скорости появления новых модулей и как итог плачевному для компании состоянию болота. Все эти фреймворки хороши низким уровнем вхождения для новичков, а компании думают что это поволяет им быстро расти
Роман Мирр, сейчас про Azure не смогу сказать так как еще не достаточно его изучил, но у AWS много чего интересного. У них прекрасная интеграция API: API Gateway + Lambda + Cognito. Отличный CDN Cloudfront. Автоматически масштабируемые базы RDS и Dynamo DB. отказоустойчивость с балансировкой ELB + EC2 Auto Scaling. Быстрый кэш ElastiCache. Стриминг данных в Kinesis,.... да даже хранилище S3 с durability 11*9.
Я могу их сервисы до утра перечислять - их действительно много (так что я даже сейчас сдаю сертификацию на AWS Solution Architect Associate ).
Стоит добавить что всю свою инфраструктуру Netflix держит в AWS (по их словам) и может полностью ее развернуть из единого JSON файла CloudFormation за 10 минут (заявляли на Devoxx)
egyptForce, прочитайте про генерацию сигнатур и валидацию токенов JWT. Об этом как раз популярно рассказано везде где только можно. В частности в том ролике что я скидывал выше
egyptForce, очень грустно что вы не ознакомились с теми материалами что я дал. Там как раз есть про авторизацию и аутентификацию. Но постараюсь вам таки ответить по пунктам.
1. Есть Authorization Server и есть Resource Server. Первый только выдает токены, а второй данные.
2. У всех (или почти всех) сервисов есть API по которому можно получить данные пользователя
3. Данные пользователя выдаются по токену. В токене написано от чьего имени выполняется операция (как ваш паспорт)
4. токен может быть украден. Поэтому токенов несколько - есть Access Token и Refresh Token. Токены имеют срок жизни, поэтому регулярно их надо обновлять
5. в OIDC есть еще ID токены, с ними интереснее и безопаснее
Запорожченко Олег, у вас достаточно большая компания, а их не так и много, как показывает практика. Часть людей от вас же уходит (так или иначе) и кто их наймет? Такие же как вы.
Что касается по технологиям и скорости разработки - AWS, Azure. Если вы знаете более быстрый способ запустить проект - пример архитектуры в студию
Роман Мирр, да, их несколько. Но про "на расхват" это сильное заблуждение.
Компании не любят брать джунов по тому что их надо учить (читай тратить ресурсы более дорогих и опытных сотрудников). Число рассматриваемых кандидатов сужается и очень сильно. В результате продукты на Ruby с каждым годом активнее выходят с рынка и заменяются другими ЯП и фреймворками. те же что решаются брать джунов как правило страдают из-за качества их кода и допускаемых ошибок, не говоря уже о растраченных бюджетах (Ruby программистам платят несколько больше из-за их редкости в природе)
Чтобы понимать какой адекватный стек технологий сейчас есть стоит посмотреть на то что используется в самых крупных компаниях (облака), а это AWS, Azure, GCP. получаем: Node.js, Python, Java, C# (.NET Core) и Go.
И тут нет ни Ruby, ни PHP. А такие компании задают темп. Конечно, компаний много, у всех свои потребности, все любят экономить, но происходит постоянная ротация технологий и языков. PHP самый старый на этом рынке и с самым большим багажом опыта, библиотек и комьюнити.
Роман Мирр, основа любого рынка это спрос и предложение. Например, вы компания и вам необходимо развивать продукт. Вы предпочтете выбирать из 100 специалистов на страну или 10000 специалистов на город?
Или вы соискатель. Вы хотите лишиться работы (не важно по какой причине) и искать следующее место по вашим навыкам полгода?
Александр Козак, браузер он на вашей локальной машине. Вы говорите о двух сайтах. Это значит что проблема в межсетевом взаимодействии между ними. Проблема не относится к программированию, а находится на уровне системного администрирования.
Консоль вы используете у себя на локальной машине или на другом сайте?
Александр Козак, тогда получается что у вас действительно отсутствует возможность достучаться до ресурса. Если вы это на удаленном сервере, то, возможно, файрвол. Если с локальной машины - есть ли доступ, например, через браузер?
Вопрос именно в доступности. Если удаленный сервер то есть ли доступ к другим ресурсам оттуда?
Артем, архитектура она такая) подождем ответа автора. 2 архитектора на сломавшего себе голову недостаточно опытного, полагаю, разработчика. Справимся) тем более что задачка, вроде, интересная
