Thrift в качестве REST API

[vladqa]

А почему остановились на Thrift, а не на gRPC? В свое время нас смутило слабое развитие проекта.

[creker]

Ладно бы слабое развитие. Для меня основная проблема трифта это полный хаос в реализациях для разных языков. Большинство сделаны кое как без какого-то единого направления. Некоторые фичи отсутствуют, другие реализованы совершенно неидиоматично для конкретного языка. Тесты порой отсутствуют. Собственно, одна из причин, почему трифт для меня это скорее генератор классов из IDL с сериализаторами, а весь транспорт и обвязка пишется своя. Весь их RPC стэк для меня бесполезен. Получается прямой конкурент протобуферам.

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

[gubber]

У нас уже был использован Thrift для межмодульного взаимодействия. Не хотелось вводить ещё один язык.
Плюс не всегда «слабое развитие» это критический минус. Если продукт решает свои проблемы, и ты не планируешь использовать неподдерживаемые фичи. То это не является критическим местом.
Выбирая из пары развивающихся продуктов, которые только выходят на рынок, тут я соглашусь, что надо смотреть на динамику развития.

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

Не знаю, что уважаемый creker подразумевал, что весь транспорт и обвязка пишется руками. Если то, что приходится писать свой сервлет, для работы через http протокол. Или поднимать ручками сервер для работы на сокетах

@Component
class ThriftAdsServer @Autowired constructor(
		@Value("\${thrift.server.port}")
		private val serverPort: Int,
		handler: AdsService.Iface) {

	companion object {
		private val logger = LoggerFactory.getLogger("THRIFT-SERVER")
	}


	private val server: TServer

	@PostConstruct
	fun startServer() {
		logger.info("Thrift server starting at port $serverPort")
		thread(start = true) {
			try {
				val serverTransport = TNonblockingServerSocket(serverPort)
				server = THsHaServer(THsHaServer.Args(serverTransport).processor(AdsService.Processor(handler)))
				server.serve()
			} catch (e: Throwable) {
				logger.error("Server was crashed.", e)
			}
		}
	}

	@PreDestroy
	fun stopServer() {
		logger.info("Try to stop thrift server serving at port $serverPort")
		if (server.isServing) {
			server.stop()
			logger.info("thrift server was stopped")
		} else {
			logger.info("Server wasn't started")
		}
	}

}

То по мне это не большая проблема: написать 40-50 строчек кода для одного сервиса.

[creker]

Трифт это не просто IDL с генераторами, а еще RPC стэк — т.е. сервисы с методами в IDL, сервера и клиенты в библиотеке. Вот это вот все довольно сломано у них и криво написано в разных языках. Поэтому для меня трифт заканчивается на TBinaryProtocol и TCompactProtocol, когда я получаю сериализованный массив байтов. Все остальное пишется самостоятельно на голых сокетах.

[Kaer_Morchen]

Поправьте меня если я не все понял, но думаю у вас было бы значительно меньше проблем, если бы:
1. В начале 2017, начиная новый проект, вы вызяли бы не архаичный REST, a JSONAPI, который более строгий и при этом имеет больше возможностей.
2. За место fuxtures использовали mirage, поддержкой которого занималась фронтенд сторона.
3. Имели бы четкую документацию API, изменения в которую разрешалось только после ревью и согласования всех кто с ней работает.
4. Писали бы тесты которые выявляют все ошибки API как на бэкенде так и на фронтенде.

И вообще судя по описанию проблемы у вас скорее беда с культурой разработки в команде, а не трудностью согласовывать API, так как это скорее следствие, а не причина.

[gubber]

Проблема не столько в том, какой набор адаптеров мы выбрали, а в том, что возникают проблемы с синхронизацией серверного и клиентского представления API. Чтобы поддерживать возможность работы команд бекенда и фронтенда независимо друг от друга.
Мы mirage и используем. Дело в том, что при таком подходе для изменения API ты должен вносить несвязанные изменения и на стороне клиента и на стороне сервера. В итоге конфигурация для mirage разрослась. Плюс, как я писал некоторые разработчики меняя модель данных на сервере не всегда меняли модель данных на мираже. Т.е. у нас в mirage есть представление списка сущностей. Список из 20 — 30 записей. И добавление одного поля в данный список приносило много боли.
Когда модель состоит из десятка сущностей — это не очень проблемно, когда количество сущностей кратно возрастает, то возрастает и стоимость «ревью».
Если можно убрать момент «ревью»API, то лучше его убрать.

Писать тесты для выявления ошибок API, это опять вопрос синхронизации. Как можно защититься от того, что разработчик напишет тест только для бекенда, а для «фронтенда» забудет?

Сейчас же с выносом API в единое место, у нас есть гарантия на уровне компиляции, что модели для сервера и клиента будут согласованы. Т.е. во время сборки проекта будет подложена последняя версия API. До этого гарантией служили «соглашения».

[Kaer_Morchen]

Дело в том, что при таком подходе для изменения API ты должен вносить не связанные изменения и на стороне клиента и на стороне сервера.

Да это плохо, этого нельзя было допускать с самого начала. Фронтенд и бэкенд должны жить независимо друг от друга. У них есть связующее звено — спецификация протокола и документация — API. Они не должны залазить во внутреннюю кухню другой стороны, а лишь соответствовать текущей документации. Вносить правки в документацию API можно только по согласованию. Все. Если вам нужна защита от дурака или случайно ошибки можно написать везде тестов. Тесты фронтенда должны проходить проверку соответствия внутренней структуры моделей и текущей документации, а тесты бэкенда аналогично проходят по своей внутренней структуре.

Мне всегда казалось что это какие-то капитанские вещи.

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

Ну вот это и есть рука лицо и отсутствие культуры. Как один разработчик может внести изменения в что-то что затрагивает другие части системы без элементарного уведомления, не говоря уже об согласовании. Ну вот поменял бэкендер api и структуру в mirage, а правки в бизнес логику кто вносить будет?