raingo

Через миддлвейр.

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

Я увидел в Вашем вопросе две части.

Как правильно организовать деплой (выкладку работоспособного кода на сервер)?

В самом простом случае Вам подойдет связка ssh + git pull на сервере. В этом случае на сервер будут доставлены патчи коммитов, которые есть в репозитории, но еще не появились на сервере, т.е. «только обновления файлов, которые сейчас существуют». Этот метод довольно подробно обсудили в ответах на другой вопрос.

Если хочется автоматизировать процесс, что похвально, то я вижу три доступных инструмента для этого: Capistrano, Mina (мой персональный фаворит) и Vlad the Deployer. Все три проекта схожи по сути. Принцип их работы таков:

1. Подключиться к целевому серверу.
2. Залить обновление кода из репозитория.
3. Выполнить предписанные Вами инструкции (перезапуск демонов, сброс индексов, обновление структуры БД и прочее).
4. ...
5. PROFIT!

Инструменты просты, переход на них — дело одного выходного дня, и может быть сопряжен со сложностями только в связи с новизной.

Как организовать процесс тестирования?

Если Вы еще не определились с методикой тестирования (Test Driven Development, Behavior Driven Development, Лень-Driven Development), то Вам следует для начала заняться именно этим.

Скорее всего, тесты будут выполняться на Вашей локальной машине, пока Вы пишете код. Используя RSpec, я держу открытым Guard. Guard отслеживает изменения в коде и запускает набор юнит-тестов, которые покрывают измененный код. Весь процесс занимает не больше минуты-двух, и особо не напрягает. Как только я вижу провалившийся тест, я меняю код до тех пор, пока он не станет зеленым. Пока тестов мало (это не самый лучший знак, к слову), Вы работаете один, локального запуска перед деплоем может оказаться достаточно — например, чтобы проверить релиз на доступность критического функционала: регистрации, покупки, создание постов и т.п.

В какой-то момент речь может зайти о Continious Integration. Это возможность иметь стабильный билд в любой отрезок времени, а так же принимать решение о годности каждого отдельного коммита. Сопряжено с деплоем кода на integration-сервер и запуском на нем тестов. Скорее всего, это Вас не интересует, если Вы не работаете в команде. Но, для полноты картины, Вы можете понаблюдать за билдами на Travis CI известных Open Source проектов: Symfony 2 и Ruby on Rails.

Таким образом

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

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

echo по умолчанию выводит данные не на экран а в STDOUT.

STDOUT может быть перенаправлен на экран (по умолчанию), или в файл, или в браузер и так далее, в зависимости от того, откуда и как был выполнен echo

json представляет собой текст.

Да готов, я использую
Не смотря на весь мой опыт в android, целый ряд кейсов мне проще и быстрее сделать на react native
Плюсы

• Redux архитектура - это реально удобно (redux можно заменить на flux, mobx и тд не суть)
  
• Легко организовать команду разработчиков, ввести нового человека в проект куда проще, по сравнению с нативной разработкой
  
• Тесты даются малой кровью и они реально полезны
  
• Возможность переиспользовать код с фронтендом
  

Минусы

• Нужно закладывать время на обновления rn, релизы уже реже, они менееболезнены, но тем не менее
  
  

"Я тут сколотил несколько табуреток за пару вечеров. За 5 дней 3 продажи, и то по друзьям. Как сделать так, чтобы ко мне приходили и покупали табуретки? Вкладываться в рекламу, открывать мебельный магазин не вижу смысла, я же не диваны делаю...".

"Я тут сайт про бабочек слепил за пару вечеров. За 5 дней 3 захода - 2 от друзей и 1 от робота гугла. Как сделать так, чтобы ко мне трафик повалил? Вкладываться в контент и seo-продвижение смысла не вижу, не пластиковые окна же продаю...".

Думаю, смысл понятен:)

Никто не рыскает в песочнице playmarket в поисках никому неизвестных головоломок, слепленных на коленке за пару вечеров. Никто не ходит по квартирам со словами: "Вы ничего не продаете? А то мало ли, может сделали чего за пару вечеров, а за рекламу платить кайфолом"))

Playmarket - всего лишь платформа, не гарантирующая установки. Ближайший пример - хайповое нынче приложение Nimses. Было выпущено в феврале и 4 месяца висело мёртвым грузом (несмотря на всю "инновационность" и философию, ага), пока разработчики не нашли бюджет на:

• массовый посев промо-публикаций по онлайн-сми;
  
• проплату рекламы у медийных лиц (Иван Дорн и пр. "ангелы");
  
• рекламную бомбардировку по всем каналам.
  

И только после этого начался хайп, ад и Израиль, топ-1 App Store и т.д.

как набрать этот самый "рейтинг", чтобы люди могли находить игру хоть в поиске?

Усиленно продвигать, по-другому никак. Даже о хайповых приложениях (типа pokemon go, prisma) мир должен узнать откуда-то, прежде чем сойти по ним с ума.

1. Сначала сделайте простой запрос (без авторизации) для получения произвольного кода (на сервере генерируем случайный ключ и возвращаем)
2. Полученный ключ (code) кодируем на клиенте через SHA256 (code+username+password)
3. Делаем запрос авторизации отправляя шифрованный код
4. На Сервере проверяем в базе комбинацию SHA256(ключ+полеUSER+полеPASSWORD). Если нашли - Вуаля! и убиваем ключ

Таким образом будет отправляться всегда новый код для авторизации и снифферы не уловят ваши данные.

Ход мыслей у вас правильный - в DTO кладете весь дескрипшн и линк на сервис выдающий изображения. Например myservice.myimageresource?imgId=12345.
Ресурс может быть либо сервлетом либо рест ресурсом. Картинку берете из базы и сразу отдаете байтовым потоком клиенту по GET запросу. Писать во временную папку не надо.

В ответ на ваш коммент отредактировал тут -так как тут есть теги для кода.
Вот сильно упрощенный пример сервлета, отдающего картинку.

public class PreviewServlet extends HttpServlet {
	
	private static final long serialVersionUID = 1L;
	
	//  это ваше DAO
	private PreviewService previewService = Fascade.getPreviewService();

@Override
	protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
		response.setContentType("image/jpeg");
		//парсим id картинки из запроса
		int imageId = Integer.parseInt(request.getParameter("id"));
		//Тут вы получаете  Entity вашей картинки, одно из полей у которого является массивом байт
		Preview preview = previewService.getByImageId(imageId);
		byte[] bytes  = preview.getBytes();
		response.setContentLength((int) bytes.length);		
		// получаете поток для своих нужд
		ServletOutputStream outStream = response.getOutputStream();
		// отсылаете картинку на клиента
		outStream.write(bytes);
		// закрываете поток
		outStream.close();
	}
}

Почти подобным образом можно и через рест ресурс отдать.

У React ниже порог вхождения, но если для создания соц. сети, то тут есть подводный камень в виде пользовательского соглашения - если напишите конкурента фейсбука на React, то фейсбук имеет право прийти и нагнуть вас за такие дела. Не в курсе убрали они это или по сей день актуально.
И зря вы так боитесь Redux изучать там практически нечего - есть статья в картинках как для детей, и мучиться с ним вообще не надо. Мне так думается, что с новым ангуляром вы намучаетесь намного больше, чем с React + Redux (Typescript + RxJS + DI + особенности фреймворка + подводные камни).
В остальном полностью согласен с Олег Гамега.

В голове полная каша. Примерно 70% указанных выше пунктов неточны или совсем не верны. Стоит взять любой фреймворк(например angular 1.x, как самый простой и быстрый для изучения) и сделать небольшой spa(можно прям из туториала angular-phonegap). Затем к этому туториалу добавьте бэкэнд в виде экспресса. Большая часть вопросов отпадет сама собой. Что касается изучения уже актуальных фреймворков, несмотря на огромную разницу в реализации общие подходы у ng2/react похожи (components, unidirectional data flow, ...) если понимать сами подходы - изучение основ конкретной реализации не должны занять больше недели. Намного больше времени уходит на изучение экосистемы(flow/typescript/webpack и т.д.)