jacob1237

Если требуют скан паспорта - рекомендую для начала собрать побольше информации о работодателе.
Вполне вероятно это может быть мошенничество. Целью мошенничества в данном случае могут быть Ваши персональные данные, находящиеся в скане паспорта (серия/номер, адрес прописки и т.д.).

К тому же не припоминаю никого кто бы работал через Western Union (очень популярную у мошенников, кстати) в последнее время - в основном это Skrill, Paypal и Wire Transfer.

Не высылайте незнакомым людям скан паспорта, если не уверены что это "настоящая" организация!

Python считается медленным, потому что он интерпретируемый и в стандартной реализации интерпретатора (CPython) нет таких вещей как JIT компиляция.
Таким образом JavaScript (на основе V8), к примеру, обгоняет его по скорости.
Кроме того, в ряде бенчмарков Python3 оказывается медленнее чем Python2.

Однако медленный - понятие относительное. В Python сильно развита система использования внешних модулей/динамических библиотек, есть возможность писать модули на C/C++, использовать внешние динамические библиотеки с помощью ctypes и т.д.

Грубо говоря, когда нужно ускорить какую-то часть программы за счет выноса её на более низкий уровень, Питон никак не будет мешать Вам это делать.

При этом Питон останется тем высокоуровневым "мостиком", который позволит продолжать решать задачу абстрагировавшись от всяких технических моментов (работа с памятью и т.д.).

Не указали какого типа у Вас авторизация и аутентификация и какую роль играет "бэкенд" в этом процессе по отношению к API.

Предположу что авторизация session-based и бэкенд хранит именно сессионные данные, тогда Вам необходимо использовать токены для авторизации, например JWT.
Таким образом слой API не будет иметь никакой связи с бэкендом при авторизации запросов (именно авторизации), т.к. все необходимые данные будут "зашиты" в токене.

Если же у Вас слой API служит только для того, чтобы отображать (проксировать в каком-то смысле) RESTful запросы на внутренний API или протокол (я так понял что WCF у вас в стэке именно об этом) и Вы хотите просто сохранять запросы на сервер (которые должны, видимо, быть больше на запись чем на чтение), воспользуйтесь промежуточным ПО, которое даст возможность складывать в очередь эти задачи.

Примеры ПО: Redis, Beanstalkd.
В первом воспользуйтесь структурой данных LIST, а второй как раз только под это и заточен (не забудьте настроить persistance чтобы не терять данные).

Но т.к. у Вас Windows, то наверное больше подойдет что-то типа hangfire.io
Однако у вышеперечисленного софта есть форки и скомпиленные под Windows бинарники.

По поводу пиков - на то они и пики. Судя по всему, таков характер активности Ваших пользователей.
Я бы в таком случае просто проанализировал характер и время возникновения пиков и подумал бы как можно решить эту задачу предусмотрев просто дополнительные мощности для этого и масштабировал бы воркеров on-demand, т.е. по мере возникновения активности наращиваем мощности, по мере снижения - уменьшаем. Но это больше инфраструктурный вопрос.

Возможно даже что его получится решить через Rate Limiting. Либо своими силами, либо при помощи сервисов типа Apigee: docs.apigee.com/api-services/content/rate-limiting.

К сожалению именно по стэку .NET не подскажу, т.к. сам работаю в другом стэке. Но принципы тут общие.

Ваша задача с категориями не относится к контексту Laravel - это задача о хранении деревьев в СУБД.
Рекомендую ознакомиться вот с этим ответом: https://toster.ru/answer?answer_id=952447#answers_...

Принадлежность товаров нескольким категориям в реляционных СУБД (если Вы работаете именно с ними) оформляется как связь "многие-ко-многим" (many-to-many).

Роутинг Вы уже реализовали в своем ответе. {category} {subcategory} {productID} - это параметры роута, которые будут передаваться в контроллер (документация).

В контроллере просто вытаскиваете эти параметры, фильтруете и подсовываете в SQL запрос. Хотя {category} (как впрочем и subcategory) здесь даже будет лишним. Но для красоты можете и оставить.

К сожалению найти хорошего разработчика действительно непросто.
А хороший разработчик на удаленке - это вообще отдельный "фрукт", который созревает годами.

Чтобы найти такого человека, нужно хорошо разбираться в мотивации и знать где искать:

Как правило разработчики на удаленке - люди с хорошим техническим бэкграундом и хорошим английским (работают в интернациональных командах).
Это в каком-то смысле поднимает планку по з\п (первый факт).

Что касается Upwork - здесь очень тяжело найти реального разработчика. Upwork никак не фильтрует уровень таких специалистов. И надо признать, не особо эффективно борется с различного уровня мошенничеством, как то: накрутка отзывов, подделка личности и т.д.
Процентов 80 там (цифра просто из головы, прошу не принимать близко к сердцу) - это низкоквалифицированные рабочие(либо посредники) с проблемами в само мотивации. Это ни хорошо ни плохо - это факт (номер два), потому что мотивировать себя на удаленке действительно непросто, особенно если ты не любишь свою работу (к сожалению сейчас в IT попадает все больше "случайных" людей из за хайпа и денег).

Факт номер три - большинство хороших разработчиков получают огромное удовольствие от создания нового, решения сложных проблем, а также от взаимодействия с технологиями (чем продвинутее, тем лучше). Поэтому все что Вы можете сделать с точки зрения контроля - установить ограничения на условия задачи и просто не мешать (это я о ежедневных отчетах).

Тем не менее, контроль за бюджетом и сроками очень важен, и это задача из дисциплины управления проектами.
Разработчики этим, как правило, не занимаются (а если и занимаются, то опытные, и попросят за это больше $$).
Поэтому чтобы контролировать ход работ по проекту, Вам (или Вашему менеджеру проекта) необходимо разработать (либо взять существующие) соответствующую методику (например Scrum). Не обязательно копировать 1в1, просто взять то, что нужно, в зависимости от проекта и размера команды.

Например разбейте ход работ на итерации (длиной в 2 недели). В каждой итерации выделяйте какое-то время на декомпозицию и оценку задач. Старайтесь по окончании каждой итерации получать видимый и работоспособный результат, прежде чем приступать к следующей (грубо говоря, отчетный период - каждые две недели).
Используйте инструменты для совместной проектной работы - Trello, Jira и т.д.

В общем большой упор нужно делать именно на психологию и установление доверительных отношений с разработчиками, потому что интеллектуальный труд очень зависим от этих вещей (и еще от денег, конечно же).

Конечно это не означает, что тех кто откровенно кладет болт на работу нужно уговаривать и убеждать поработать. В таком случае это просто не ваши "пассажиры".

Ну и искать рекомендую не на бесплатных фриланс-биржах по ключевым словам, а на специализированных площадках: тематических тусовках (чаты/форумы по технологиям/фреймворкам), специализированных биржах с отбором кадров (типа Toptal), ресурсах посвященных работе (типа Djinni.co).

Также порекомендую самому проводить какой-либо простейший отбор/тестирование кандидатов, особенно если кандидаты с фриланс-бирж и не топовые профили.

Минус первого подхода в том что могут возникнуть коллизии и 2 сервера могу взять одновременно задачу на себя и будут выполнять двойную работу

Зависит от технологий, которые Вы собираетесь использовать. У Вас в варианте №1 структура данных с задачами для воркеров будет называться распределенная очередь (shared queue). У этой структуры данных как раз-таки основная задача - раздавать данные юнитам, предотвращая дублирование и негативные эффекты типа race condition и т.д.

В разных программных пакетах реализуется по-разному. Порекомендую глянуть например на Beanstalkd, где все Ваши проблемы уже решены, либо воспользоваться встроенной в Redis структурой данных List. Она в принципе то что нужно и делает.

Однако преимущество Beanstalkd будет в том, что он специально заточен именно под очереди задач: поддерживается сортировка задач в заданном числовом порядке, резервирование задач, автоматическое снятие резерва при превышении времени на обработку и др.

Плюс предусматривает возможность хранения задач на жестком диске (с ключом -b) помимо хранения в памяти (что в Redis реализуется только через слепки (snapshot), либо через полный лог операций - что не есть оптимальный вариант).

Вы сами на свой вопрос и ответили в комментарии. Вам как раз нужен BaaS.

Например:
https://backendless.com
https://firebase.google.com/features/

Из основного судя по всему потребуется авторизация через соц. сети. И там и там это есть, но вроде в FireBase побольше соц.сетей в данный момент.

Конечно предварительно нужно понять какой функционал Вам нужен, т.к. из вопроса это вообще не ясно.
Но совсем без кода скорее всего не получится обойтись.

После того как проанализируете базовый функционал, подумайте что будет быстрее - написать свой простенький бэкенд, либо штудировать доки стороннего сервиса, потому что время на изучение API тоже может уйти немало, если нужно писать какие-то нестандартные фичи.

То что Вы пытаетесь реализовать, называется наследованием таблиц (Table Inheritance) - это такой способ эмулировать наследование классов в реляционных СУБД.

Всего существует несколько известных вариантов решения такой проблемы, например Single Table Inheritance и Class Table Inheritance (это если не учитывать нативную поддержку подобных вещей в некоторых СУБД, например PostgreSQL).

Полиморфные же связи (которые по-дефолту в Laravel) - это не очень хороший способ реализации, потому что не позволяет поддерживать целостность связей на уровне СУБД. Однако можно использовать и его, если Вам эта целостность не очень важна (ее надо будет поддерживать на уровне приложения).

К сожалению Eloquent не поддерживает ни Single Table Inheritance, ни Class Table Inheritance (зато их поддерживает Doctrine из Symfony), поэтому придется писать вручную.

Прежде чем это делать, я бы Вам посоветовал разобраться как Profile относится к User и OrgAdmin.
Является ли Profile подвидом пользователя (из названия честно говоря не понял), или же это просто набор дополнительных полей, которые можно оформить в виде связей?

Если и Profile и OrgAdmin - это подвиды (подтипы) пользователей со своим собственным набором полей, то Вам нужно добавить в общую таблицу отдельное поле type (это называется дискриминатор), в котором у Вас будет проставлен тип пользователя. Например 1 для User, 2 для Profile и 3 для OrgAdmin.
Короче очень похоже на стандартный Polymorphic Relationships из Laravel.

А потом переопределяете у модели User функции newFromBuilder() или newInstance() в которых Вы укажете какие классы моделей создавать для конкретного type. Вот например статья.

Дальше для Class Table Inheritance можно в трейт поместить функцию сохранения и родителя и потомка, потому что сохранять их придется вместе (на уровне БД), в зависимости от измененных свойств. Кроме того, нужно будет позаботиться об отображении (mapping) атрибутов родителя на потомков (__set и __get), на случай если вдруг захочется делать вот так (представьте что атрибут name принадлежит родителю - модели User):

$profile = new Profile();
$profile->name = 'John Doe';
$profile->save();

Короче это гемор в Laravel. Поэтому перед тем как делать, подумайте можно ли решить задачу проще - например через Single Table Inheritance, поместив все атрибуты в одну таблицу, либо делайте через стандартные полиморфные связи.

Когда я решал эту задачу, я все вышеуказанные функции помещал в трейты. Может когда-нибудь дойдут руки запилить отдельную библиотеку или отправить патч в само ядро фреймворка.

Погуглите по указанным ключевым словам (паттернам), может что уже появилось для Laravel.