У JWT есть один идеальный вариант применения: если в системе используется несколько/много серверов, которые не связаны между собой одним доменом (например в ситуации с микросервисной архитектурой) и которые максимально децентрализованы.
Вот в этом случае, когда нужно сделать Single Sign On (SSO), то есть единую точку аутентификации, применение JWT как раз весьма удобно.
Пишется дополнительный сервис аутентификации, который отдает клиентам refresh_token и access_token и периодически обменивает access_token на новый.
Все остальные сервисы должны лишь проверить access_token на правильность, т.е. сверить криптоподпись и текущее время. Если токен еще актуален, то авторизация пройдена и можно делать работу.
Во всех остальных случаях удобнее взять cookies и не забивать голову. Если у вас нет необходимости делать Single Sign On, то Вам, вероятно, и не нужен JWT.
В конечном счете JWT это просто стандарт токена авторизации (с использованием JSON). Саму схему авторизации он не регламентирует.
AnjeyTsibylskij, у Sphinx и ElasticSearch собственная база данных. Эти поисковые движки хранят ИНДЕКСЫ Ваших данных, и при поиске Вы работаете напрямую с ними, а не с оригинальной БД.
А когда данные были найдены, по полученным результатам уже делаете запрос в основную БД, вытаскивая всю необходимую инфрмацию.
То есть поисковые движки это "прослойки" для основной БД, которые сами хранят какие-то данные и ищут по ним.
Но прежде чем использовать их, нужно будет составить индекс и настроить синхронизацию.
Трудно сказать с первого взгляда. У компании судя по всему есть офис в Киеве, но платежи при этом идут через Western Union (судя по вакансии) - это странно.
Рекомендую удостовериться что Вы общаетесь с реальным работодателем.
Попробуйте позвонить по указанным телефонам на сайте прямо в офис компании и уточнить эти вопросы.
Не стесняйтесь также звонить прямо в европейские офисы. Но начать рекомендую с Киева.
Кроме того, з\п 150-300 евро за "опытного разработчика на CMS Wordpress. Wocommerce" выглядит очень странно (при этом пишут что готовы взять студента), т.к. те кто в теме, знают что опытные вордпресс разработчики могут получать офферы на 3000$+ а то и еще больше (потому что на Wordpress есть куча известных и высоконагруженных сайтов).
1) Не знаю какой СУБД пользуетесь, для PostgreSQL: https://www.postgresql.org/docs/9.5/static/indexes... , для MySQL просто создайте индекс по полю - к сожалению InnoDB и MyISAM их (HASH) не поддерживают (будет использован B-Tree)
4) $subcategory->products()
->orderBy('sort')
->paginate(20)
->appends($request->except('page'));
1. Создал бы HASH индексы в БД по полям `url` в Products и Categories в обязательном порядке - это значительно ускорит процесс выборки по текстовому значению url на больших таблицах
2. Сравнение `$subcategory->parent == $category` заменил бы на `$subcategory->parent_id === $category->getKey()`, чтобы при обращении к $subcategory->parent лишний раз не дергать базу данных (т.к. Eloquent в этот момент выполнит запрос на выборку parent)
3. Сортировал бы продукты на стороне СУБД (с помощью $subcategory->products()->orderBy('sort')->get())
4. Применил бы pagination к продуктам
Примерно так. При таком подходе в худшем случае у Вас получается три отдельных SQL запроса на страницу (категория, подкатегория, продукты). Есть еще куда оптимизировать, но пока что Вам, подозреваю, на данном этапе это не очень нужно.
Просто подумайте как Вы сами для себя дифференцируете subcategoryUrl и productUrl. Точно таким же образом заставьте это делать и роутер.
Либо как еще один вариант (если они реально ничем не отличаются), эти два роута можно объединить в один и делать два SQL запроса по-очереди. Первый на товары подкатегории, второй - на товар из категории. Делать их по-очереди: "если первый не подошел, пробуем второй".
Но сразу скажу что это не очень оптимальный вариант. Хотя для небольшого магазина работать будет =)
Здесь имеется проблема с порядком следования маршрутов и их определением. У Вас второй и третий маршруты с точки зрения роутера ничем не отличаются, кроме названий параметров, поэтому взят будет тот маршрут, который объявлен первым (как раз categoryUrl/subcategoryUrl).
В данном случае я бы подумал над тем как поточнее определить маршрут для productUrl. Если он подчиняется какому-то правилу, можно попробовать использовать регулярные выражения: https://laravel.com/docs/5.4/routing#parameters-re...
В общем нужно сделать все, чтобы снизить "похожесть" этих двух маршрутов, тогда проблема исчезнет.
Технически возможно. Но тогда Вы потратите очень много времени чтобы написать то, что уже написано (целым сообществом). Рекомендую все-таки не париться с этим, а взять что-то уже готовое.
Так будет гораздо проще и быстрее (несмотря на то, что придется изучать новую документацию), если Вас интересует только изучение самого подхода DDD.
Как только попробуете, освоитесь, тогда уже будет проще понять хочется ли Вам двигаться "вглубь" самих технологий.
Рад что помог, но в одном сообщении к сожалению всего не опишешь по этой тематике. Там есть еще третий вариант, называется Concrete Table Inheritance - это когда есть несколько отдельных таблиц, у которых одинаковые поля просто дублируются (свои для каждой). Но в таком варианте общего идентификатора в БД у них не будет.
Это синтетические тесты, которые реальную картину Вам не покажут. Если заглянете в исходники тестов, то увидите, что тестируется лишь алгоритм нахождения простых чисел (primes), то есть фактически только арифметика (ну и циклы).
Очень дискуссионная тема. Не могли бы Вы привести ссылки на какие-либо нормативные документы? Дело в том, что если исчислять налогооблагаемую базу именно так как Вы говорите, то в таком случае сумма комиссионных (а также сумма, изымаемая банком-посредником при транзакции) попадает под двойное налогообложение.
То есть сама биржа получает прибыль и платит с нее налоги, и с той же прибыли платите налоги и Вы.
Насколько мне известно, у России есть договоры с разными странами для предотвращения двойного налогообложения.
Не могу сказать отражены ли там такие случаи, но выглядит ситуация довольно абсурдно.
Также на каких-то форумах по юридической и бухгалтерской помощи видел обсуждения (уже не помню ссылки), в которых приводились именно такие аргументы (про двойное налогообложение), и что предприниматели просто должны производить расчет с суммы, полученной именно на расчетный счет.
Upwork, наоборот, запускается (точнее уже давно запустился) и с ним идет слияние oDesk и Elance. Я бы не стал говорить прямо что "воруют деньги" пока нет конкретных фактов, возможно это можно как-то списать на идиотов из Risk Management Team.
Однако вся эта ситуация, по косвенным признакам, выглядит как какое-то мошенничество: мол, смотрите, у нас есть подозрения, но мы не скажем какие, поэтому мы заблокируем ваш аккаунт и деньги на нем, а вы докажите что вы не верблюд.
Если бы Вы видели настоящий индусский код, написанный самым настоящим индусом, "поднимающим свой профессиональный уровень", думаю у Вас было бы иное мнение)
И да, конкуренция не растет. Есть всего лишь фикция. Как думаете, почему в Европе давно уже бьют тревогу по поводу дефицита кадров в IT? Почему бы тогда им не пригнать к себе толпы индусов, готовых работать за еду, ведь их уровень все-таки растет?
Ответ очевиден - там (в Индии) просто нет такого уровня подготовки. Большинство "специалистов" просто вынуждены работать на фрилансе, потому что Индия - не самая обеспеченная страна мира.
Таким образом во фриланс попадают те, кто вообще не имеет и не имел никакого отношения к миру IT.
То же самое относится и к России. Большинство "фрилансеров" просто делают вид, что они высококвалифицированные специалисты, однако реальность такова, что даже этот высококонкурентный рынок (да даже те самые лендинги), обслуживают всего несколько специалистов, а остальные просто ловят крошки хлеба со стола)
Давайте не будем обманывать себя, тут действует даже не закон Парето (80% на 20%), тут наверное все 95% на 5%, и тем самым 5% как раз и удается "столько зарабатывать на фрилансе".
Так что если ТС настоящий IT'шник, я бы посоветовал не вешать нос и повышать профессиональный уровень (и научиться хорошо и складно говорить, ведь это маркетинг). Если же нет, то давайте все-таки дадим им (95%) возможность продолжать грызть кактус)
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
Вот в этом случае, когда нужно сделать Single Sign On (SSO), то есть единую точку аутентификации, применение JWT как раз весьма удобно.
Пишется дополнительный сервис аутентификации, который отдает клиентам refresh_token и access_token и периодически обменивает access_token на новый.
Все остальные сервисы должны лишь проверить access_token на правильность, т.е. сверить криптоподпись и текущее время. Если токен еще актуален, то авторизация пройдена и можно делать работу.
Во всех остальных случаях удобнее взять cookies и не забивать голову. Если у вас нет необходимости делать Single Sign On, то Вам, вероятно, и не нужен JWT.
В конечном счете JWT это просто стандарт токена авторизации (с использованием JSON). Саму схему авторизации он не регламентирует.