Задать вопрос
alnidok

Александр Докин

Ответы пользователя по тегу Веб-разработка

  • Как сделать правильную архитектуру платных подписчиков на сайте?

    alnidok
    @alnidok
    В БД это дело логично хранить в виде таблиц пользователей и подписок. При подписке создавать запись, где хранить id пользователей (на кого и кто подписался), а также время начала и окончания подписки.

    Пример структуры
    CREATE TABLE `user` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `name` varchar(255) NOT NULL DEFAULT '',
  `type` enum('AUT','SUB') NOT NULL DEFAULT 'SUB',
  PRIMARY KEY (`id`)
);

CREATE TABLE `subscription` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `author_id` int(11) NOT NULL COMMENT 'На кого подписываются',
  `subscriber_id` int(11) NOT NULL COMMENT 'Кто подписывается',
  `created_at` timestamp NOT NULL COMMENT 'Время подписки',
  `expired_at` timestamp NOT NULL COMMENT 'Когда истекает подписка',
  PRIMARY KEY (`id`)
);

# Пусть у нас есть один автор и два пользователя:
INSERT INTO `user` (`id`, `name`, `type`)
VALUES
	(1, 'Alex Pushkin', 'AUT'),
	(2, 'Vasya Pupkin', 'SUB'),
	(3, 'Jane Doe', 'SUB');

# Один из них подписался на Автора месяцем ранее, второй недавно
INSERT INTO `subscription` (`author_id`, `subscriber_id`, `created_at`, `expired_at`)
VALUES
	(1, 2, '2020-02-15 13:46:12', '2020-03-15 13:46:12'),
	(1, 3, '2020-03-15 13:46:12', '2020-04-15 13:46:12');


    Если нам надо узнать активные подписки, просто выбираем записи с нужным автором, у которых время подписки подходит.
    SELECT * 
FROM subscription
WHERE author_id = 1 and expired_at < CURRENT_TIMESTAMP and created_at < CURRENT_TIMESTAMP;


    Дальнейшую логику, наверное, додумаете сами.

    Можете поиграться в песочнице:
    sqlfiddle.com/#!9/f4fc27/3/0
    Ответ написан
    Комментировать
    Комментировать

  • Как увеличить скорость загрузки лендинга, если он достаточно объёмный?

    alnidok
    @alnidok
    Для начала давайте определимся, какую задачу нужно решить. Либо получить максимальную оценку в PageSpeed / GtMetrix, либо ускорить первую загрузку страницы для пользователей. Поверьте, это разные вещи.

    Для первой цели просто выполняйте все возможные рекомендации инструмента проверки. Большинство из них фронтендеры решают средствами систем сборки (gulp, grunt, webpack). Т.е. из исходных dev-файлов собирается production-проект со всеми минификациями и оптимизациями. Можно обойтись и без них, используя онлайн-сервисы.

    Далее напишу о том, что действительно влияет на скорость загрузки для конечного пользователя в порядке уменьшения значимости:
    • огромные изображения
      Не нужно грузить изображение в 1Мб, если на странице будет картинка 200x200. Для этого подготовливаются миниатюры нужных размеров.
      Для уменьшения объема проводят оптимизацию (optipng, tinyjpg) и используют srcset.

    • блокирующий js
      Браузер перед рендером разбирает полученный html-код. При этом проверяется синтаксис js-скриптов на валидность, и пока он не пройдет - страница не готова для показа. Поэтому необязательные скрипты нужно загружать асинхронно. Почитайте это и это.

    • не используется lazy-load
      Представьте, что есть лонгрид с 1000 изображений, картой и кучей видео. Если все это браузер должен показать пользователю при первой загрузке страницы, представляете как долго она будет грузиться? Решение простое - использовать отложенную загрузку элементов, которые не попадают в текущую область видимости. Например так. Для jquery полно нужных плагинов. Вам обязательно нужно это сделать для яндекс-карты и большинства изображений.
      Вот удачный пример.

    • кол-во параллельных запросов с одного домена
      Например для chrome это 6 запросов, т.е. 7-й начнет выполняться только тогда, когда вернется ответ от одного из шести первых...
      Здесь пользуются рядом приемов: спрайты для изображений (всякие стрелочки, иконки меню, почему они у вас все разными файлами?), объединение всего js-кода в один файл, css-кода в один файл, а также разносят внешние данные по поддоменам, например images.example.com для изображений, static.example.com для всей статики и т.п.

    • генерация динамики на сервере
      Это относится к высоконагруженным проектам. Например когда для формирования страницы нужно брать много данных из базы, что-то с ними делать на ходу, потом идти на какой-нибудь сервис за данными и т.д. Очевидно, что генерация страницы будет долгой, причем для каждого пользователя. Решение - использовать промежуточные кеши, профилировать серверный код и т.д.


    Есть и ряд других оптимизаций, которые мало влияют на реальную скорость загрузки для пользователей, но влияют на показатель оценки в PageSpeed / GtMetrix. Например это минификация js / css / html. Или перенос всяких inline-стилей в таблицы стилей.

    Важно думать не только о первом показе страницы, но и о повторных. Нет смысла заново отдавать ему то, что браузер может кешировать. Поэтому статику отдаем с правильными заголовками (expires, etag) и в сжатом виде (gzip). Делается это средствами вебсервера. С этим у вас все в порядке.

    Подробнее про клиентскую оптимизацию тут. О чем-то я намеренно умолчал, но сервисы все это учитывают и дают свои рекомендации. Следуйте им, и да пребудет с вами Сила.
    Ответ написан
    Комментировать
    Комментировать

  • Как правильно вести разработку в нескольких ветках?

    alnidok
    @alnidok
    Нет, если редактировались разные файлы, то конфликтов не будет.

    Когда вы работаете в ветке, обязательно поддерживайте ее в актуальном состоянии мастера. Т.е. в данном случае после пуша в master (167) переключайтесь на ветку staging (104) и делайте merge мастера в нее. Если даже будут конфликты - разруливаете их в этой отдельной ветке, не трогая master.
    Ответ написан
    2 комментария
    2 комментария