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

    pro-dev
    @pro-dev Автор вопроса
    Доброго утра! С наступившим Новым годом!)

    Отличный ответ! Могли бы Вы ещё дополнить ответ, как и в каком виде хранить данные? На вопрос подписалось 10 человек. Имеет актуальность.

    Все советуют Redis. Я так понимаю в таком виде и стоит хранить? Или использовать в MYSQL?

    Если взять базу данных MYSQL, то как хранить три ваших типа? Какая архитектура таблиц? Например, для вашего типа ALL Registered Users можно создать дополнительные поля в таблице users: counter_friends, counter_comments, counter_reviews, etc... А можно создать дополнительную таблицу user_counters и добавить их там.

    Возьмем второй примитивный пример - посты в блоге. У которых есть счётчики: количество комментариев, к. отзывов, к. подписчиков и так далее. Как быть в этом случае?

    В вашем типе Public какую структуру иметь счетчиков? Это отдельная база счетчиков? Или это отдельная таблица?)

    Если не сложно - можете дополнить свой ответ или ответить в комментариях? Очень волнующая тема. Ваш ответ внёс некие понимания и в целом он хороший!

    Благодарю!
  • Как передавать разрешения для API?

    pro-dev
    @pro-dev Автор вопроса
    2,3 как раз одно и то же) Сейчас стоит OAuth2 и как раз разрешения там задаются через scope. Мне показался этот вариант больше подходит для глобальных вещей с общей авторизацией. Где реализован доступ к самим сервисам. Неужели туда питают все, как в глобальный RBAC?)

    Первый вариант не знаком. Почитаю.

    То есть вы тоже считаете, что отдельный экшн излишен для получения прав?
  • Как лучше организовать работу в команде? Один репозиторий или несколько?

    pro-dev
    @pro-dev Автор вопроса
    Сергей delphinpro, наверное, вы тут правы. С логической точки зрения я так и думал. Но ранее один делал все в одном) Поэтому и думаю как лучше. В любом случае спасибо за разъяснение. Если хотите можете написать в ответы. Подожду другие мнения и помечу решением)
  • Как лучше организовать работу в команде? Один репозиторий или несколько?

    pro-dev
    @pro-dev Автор вопроса
    Сергей delphinpro, можете пояснить почему?) Хочется узнать все за и против. Интересная тема)
  • Как лучше организовать работу в команде? Один репозиторий или несколько?

    pro-dev
    @pro-dev Автор вопроса
    Сергей delphinpro, нужно переключаться из репы в репу. Это не очень удобно.
  • Как правильно разделить проект на микросервисы или сервисы?

    pro-dev
    @pro-dev Автор вопроса
    alex005, понял)) Скорее всего с микросервисами я и правда переборщил) Вопрос больше о сервисах) но ссылку сохранил)
  • Как правильно разделить проект на микросервисы или сервисы?

    pro-dev
    @pro-dev Автор вопроса
    Robur, я тут совсем видимо запутался и в принципе понял, что нужны, наверное не микросервисы, а сервисы)
  • Как правильно разделить проект на микросервисы или сервисы?

    pro-dev
    @pro-dev Автор вопроса
    Спасибо за ответ. Да, скорее это больше сервисы, чем микросервисы. А как из этого можно сделать ммкросервисы? Как правильно делить? И что можете посоветовать ещё в данном подходе?

    На какие именно домены разделить и класть ли апи в разные домен или в один или разделять по путям - в целом мало разницы.

    Можете сказать в каких случаях стоит использовать отдельный домен для api, а в каких можно обойтись без домена?

    Не нашёл хороших примеров с сервисами и микросервисами. Может быть не правильно гуглил. Хотелось бы посмотреть как проектируют подобное другие. Случайно нет ли у вас ссылок?

    По авторизации уже готово. Использую OAuth2.0
  • PHPStorm + PHPUnit + Symfony не может найти класс при тестировании. Как настроить?

    pro-dev
    @pro-dev Автор вопроса
    tschin, да. Проблема похожая. Надо было подгружать /vendor/autoload.php. Поэтому не находил. Я уже решил вопрос. Просто добавил конфиг PHPUnit и подключил его ко всем тестам

    <?xml version="1.0" encoding="UTF-8"?>
    
    <!-- https://phpunit.readthedocs.io/en/latest/configuration.html -->
    <phpunit xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:noNamespaceSchemaLocation="http://schema.phpunit.de/6.5/phpunit.xsd"
             backupGlobals="false"
             colors="true"
             bootstrap="config/bootstrap.php"
    >
        <php>
            <ini name="error_reporting" value="-1" />
            <server name="APP_ENV" value="test" force="true" />
            <server name="SHELL_VERBOSITY" value="-1" />
            <server name="SYMFONY_PHPUNIT_REMOVE" value="" />
            <server name="SYMFONY_PHPUNIT_VERSION" value="7.5" />
        </php>
    
        <testsuites>
            <testsuite name="functional">
                <directory>tests/Functional</directory>
            </testsuite>
            <testsuite name="unit">
                <directory>tests/Unit</directory>
            </testsuite>
        </testsuites>
    
        <filter>
            <whitelist>
                <directory>src</directory>
            </whitelist>
        </filter>
    
        <listeners>
            <listener class="Symfony\Bridge\PhpUnit\SymfonyTestsListener" />
        </listeners>
    </phpunit>
  • Как сменить php 7.3 на Mac OS?

    pro-dev
    @pro-dev Автор вопроса
    Благодарю) Можно ещё ссылку на статью? Чтобы не потерять)
  • Как ускорить Docker на Mac OS?

    pro-dev
    @pro-dev Автор вопроса
    Дмитрий, либо без докера. Либо докер на виртуалке Ubuntu
  • Когда стоит разделять приложения?

    pro-dev
    @pro-dev Автор вопроса
    Илья, я дико извиняюсь, но только сейчас увидел ваш комментарий.. Уведомление куда-то пропало...

    сколько у вас человек на проекте?
    Пока 2-е
    Есть ли функционал который вы бы хотели масштабировать отдельно?
    Да, есть. Пока что в одном месте, но затем хотелось бы отделить на разные сервисы. Так как они логически отделены.
    Нужно понимать потоки данных, сколько запросов и как они распределены, какая нагрузка и еще много вещей
    Нагрузка пока не большая. До 50 000 посещений в месяц.
    Выделение кода в отдельное приложение (отдельный процесс) делаем
    или по организационным причинам: разделение кода для упрощения понимания или разделение кода между разными людьми/командами или требования безопасности/юридические требования.
    или это явно разные модели обработки (например АПИ для пользовательских запросов и фоновая агрегация, в этом случае у них разный хост-процесс: веб-сервер и фоновый сервис)
    или по причинам нехватки ресурсов.

    Правильно ли я понял, что под каждый сервис нужен свой API? Или весь API делается как отдельный сервис API? У меня есть сервис Аккаунт и Мероприятия. Мне в каждом из них нужно делать свою API верно?

    У меня есть сервис мероприятия. Он достаточно большой. В нем есть логические вещи, которые можно вынести в отдельный сервис. Это регистрация и счет баллов или отдельный сервис manager для управление мероприятием (регистрация, счет). Либо вообще все оставить в сервисе мероприятий. Вот с этим я не могу решиться. Сможете помочь? В принципе эти сервисы будут взаимодействовать с мероприятием, но они достаточно самостоятельные и нужны лишь только данные. Вот я и думаю стоит ли разделять их. Либо оставить в одном сервисе.
    Разделяя код в разные процессы теряется возможность очень быстро общаться через общую память.
    на первом этапе можно разделение сделать папками, а не отдельными приложениями. Как думаете на этот счёт? А уже если нужно разделить на приложения и так далее. Опять же разделение такое, что в принципе они друг с другом не особо и сильно взаимодействуют.

    Ещё есть вопрос по городам. С точки зрения базы правильно хранить города в одном месте. А везде в таблицах ссылаться по id. Получается это тоже отдельный сервис городов? Или в каждом сервисе своя нормализация по городам.

    Можем даже связаться по скайпу. Оплачу консультацию.
  • Когда стоит разделять приложения?

    pro-dev
    @pro-dev Автор вопроса
    3 кейс.
    Вы делаете несколько сложных сервисов и решаете распаралелить разработку на несколько команд. Одна команда делает "Кинопоиск", другая "Афишу". Все они обращаются к серверу авторизации из кейса 2 и бекендам из кейса 1.


    Мне больше подходит этот кейс. Но вопрос по нему. Если я разрабатываю сложные сервисы, то:
    Я сейчас разделил только на api и front. В api у меня весь api афиши, Кинопоиска и т д. Нужно ли под каждый сервис делать свой api и front. Или же это просто делить папками в api и front. Или вообще делать сервис в котором будет свой api и front? Как лучше в этом плане поступить?

    У меня сейчас есть сервис авторизации. И большой Сервис Афиша.

    У афишы есть: организаторы, участники (люди и компании), новости мероприятия, ПОДСЧЁТ результатов участников.

    И я теперь сомневаюсь по регистрации и подсчёту баллов. Может быть это отдельные сервисы? Или как вообще лучше устроить?

    Кроме того компании и люди в каждом сервисе могут повторяться. Не нужно ли людей и компаний выносить в отдельный сервис? Думаю нет. Но просто задаю кучу вопросов чтобы разобраться.
  • Как реализовать разрешения в api?

    pro-dev
    @pro-dev Автор вопроса
    BoShurik, естественно. Нужно именно для отображения. Для логики права везде проставлены.
  • Как реализовать разрешения в api?

    pro-dev
    @pro-dev Автор вопроса
    Антон, я только разрабатываю api на симфони. Как лучше права передавать при авторизации? И как быть если права изменятся на сервере? Например дали доступ к просмотру чего-либо.
  • Как реализовать разрешения в api?

    pro-dev
    @pro-dev Автор вопроса
    А если какие-то разрешения динамические? Получается при авторизации фронт запоминает одно состояние. Сервер изменил разрешения, но они не поменялись на фронте. Не очень правильно, думаю.
  • Почему Nuxt в Docker не следит за изменением файлов?

    pro-dev
    @pro-dev
    Игорь, я тоже не буду видимо. Сколько ковырялся толку нет. В интернете ничего не нашел) Вот наткнулся на вот вопрос думал моя ситуация. Но увы)
  • Почему Nuxt в Docker не следит за изменением файлов?

    pro-dev
    @pro-dev
    Игорь, понял. Благодарю. Выручаете как всегда)
  • Почему Nuxt в Docker не следит за изменением файлов?

    pro-dev
    @pro-dev
    Игорь, да может оно и не надо) Я ж откуда знаю. Просто почему то думал раз сервисы, то они и разрабатываться должны в одном месте. И информации по разработке в докере не находил. Только для prod. Но теперь, вашими указаниями понимаю, что оно, наверное и не должно быть так)) Скорее всего разработка идёт отдельно. А уже в prod используем докер. В принципе логично тоже.