В пару строк ваши задачи не решаются.
А от CRM с веб-мордами полки ломятся от предложений, включяя SAAS, а не только коробки.
Сделайте на базе любой CMS, если задачи ограничиваются приведённым списком чтобы не писать многое с нуля.
Но учитывайте, что обычно далее требуется трекинг задачи, оповещение по СМС и тому подобное, что уже решено в готовых продуктах.
сильно сомневаюсь что они решили руками соискателя кучу жара загрести
ну смешно
А вот не факт.
В наше время соискатель, особенно юный, слаб на опыт. В конечном счете никто сначала не знает, а был-ли вообще мальчик.
На самом деле это может быть хоть студент или аспирант, которому нужно сделать проект для диплома или дисера.
Поддерживаю всех выссказавшихся о том, что задание должно отнять от нескольких часов до максимум 2 дней работы и не иметь прикладного использования но лишь демонстрационное, в целях понимания уровня владения технологиями в нём (приложении) задействованными.
может но уж очень туго держать постоянное соединение
Да нет там никаких тугостей. Оптмизировать всё можно и при необходимости запустить в несколько потоков. Код, где не будет течь память и правильно настроен веб-сервер, отработает нормально. По ресурсам, понятное дело, получится прожорливее чем тоже самое на С, или даже питоне, но всё-равно вполне рабочее решение.
Суть в том что это просто геморнее, чем воспользоватья решениями специально для этого написанными.
Примеры коммерческих проектов где на виртуальном хостинге надо держать серверы на веб-сокетах мне не известны. Приведите, если кто-то знает.
Ну это решаемо, другой вопрос, нахрена?
Ладно если вы пишите не сервер для клиентов, а соединятесь сами через сокеты или открываете сокет сервер для умеющих работать с протоколом клиентов.
Но для браузера обычного это делать, создавая универсальное приложение... не оправдано. Если это корпоративное приложение или для сообщества — ещё куда ни шло.
Для остального замучаетесь писать обходные решения на транспортах лонгполлингов, флеше и xmlhttprequest.
Есть нюанс.
Если ошибка в конфиге будет, к примеру в каких-нибудь реврайтах, то у вас сервер не стартанёт после ребута.
Вот так вот.
Потому там надо юзать либо штатный чекер конфига, который не даёт ребутать сервер если есть синтаксические ошибки, либо не делать ошибок.
А что думать как перезагружать. Вполне вменяемый вариант автоматизировать задачу через cron скрипт с рестартом в случае изменения в хостах. После изменения писать требование ребута в любой файл и всё.
Есть стандартный поисковый запрос SELECT SQL_CALC_FOUND_ROWS, возвращающий, разумеется, число найденных объектов и по лимиту (постранично) сами эти результаты.
При этом на карте хочется визуализировать в виде кластеров сразу все результаты поиска.
Вопрос: как правильно организовать логику работу кластеризатора геобъектов и запрашивать данные на бэкенде.
Уточняю:
Стандартный запрос с limit возвращает первые 10-15 элементов. Для построения же кластеров нужно выбирать координаты всех объектов удовлетворяющих критериям поиска (либо показывать вообще 1 метку кластера с числом результатов на всю карту, что не правильно).
После отбора всех координат мы уже кластеризуем метки в дистанции, к примеру, 1 км, далее 300 метров, далее 50 метров, далее по 1 адресу. По аякс-запросу отдаём содержимое кластеров — новые кластеры либо отдельные метки, с этим проблем нет.
Вопрос именно в получении первичного набора данных.
Каков оптимальный выход? Всегда делать отдельный запрос для геометок? Дорого. Фактически это такой же запрос, как для ленты объектов со всеми joinами, только без лимита и с меньшим набором данных (1 поле). Боюсь что альтернативы в общем-то и нет и придётся делать отдельный запрос.