Website development
Programming
Node.JS
Amazon Web Services
Comments 17
+5

Такой жестокий vendor lock, что даже страшно думать о том, что будет, если они все-таки решат с амазона слезть (например из-за его цены :)).

0
Даже страшно подумать сколько бы они заплатили, если бы строили всё с нуля сами.
0
Вопрос в том как это всё написано. Если через обёртки и абстракции — то всё не очень то печально. Если напрямую — тогда да, жёсткий vendor lock. Приведу пример: если они используют Amazon SES напрямую, через стандартный SDK — то при изменении платформы будет большая беда. А если они написали свой интерфейс для работы с имейлами, и только подключают к нему реализацию которая использует SES — то всё будет хорошо. Для нового сервиса просто пишется новая реализация, а весь основной код даже не замечает изменений. Ну, это в идеальном мире, конечно)
0
"Мы используем Protocol Buffers для схем данных (и правил изменения схем) чтобы держать все слои распределённой системы синхронизированными, включая мобильные приложения, веб-сервисы и хранилище данных. Мы аннотируем схемы деталями конфигурации, такими как имена талиц и индексов, правилами валидации записей, такими как максимальная длина строк или допустимые диапазоны значений чисел."

Не совсем представляю, а как это можно делать. Они схему БД на протобуфе пишут?
0
Видимо описывают в proto-файлах схему и связи, да. А потом валидируют данные с их помощью.
0
Хм, может я что-то пропускаю, но насколько я понимаю, протобуф — это способ серилизации данных. Как на нем можно описывать связи, индексы?
0

Автор в оригинальном посте не раскрывает этот вопрос, но Protocol Buffers — это ещё и формат (язык) описания данных. Кроме этого, насколько мне помнится protoc, средствами которого описание транслируется в реализацию на конкретном языке, поддерживает плагины, так что можно предположить, что в том числе за их счёт это и реализовано. Впрочем, это только предположения.

0
Ну так этот язык ведь заточен под конкретную цель — эффективно упаковывать-распаковывать данные.
При чем тут схемы, индексы? О таких сущностях протобуф не знает.
Они что, свои метаданные в протобуф пакуют?
Автор еще упоминает какие-то анотации. Что интересно под этим подразумевается?
И главное, зачем городить?
0
Так то оно так, но там еще есть описательная часть. Так что в принципе, можно описывать данные на protobuf, но не для серилизации, а для валидации. Вот, например, либа для nodejs, которая ничего не серилизует и не упаковывает, а просто валидирует схемы: https://www.npmjs.com/package/protobuf-validator
0
А JSON схема чем плоха? Но дело даже не в этом. Я не понимаю мотивации в описании схемы БД в терминах протобуф IDL. Может есть какой-то годный фреймворк, позволющий удобно все эти описания переводить в DDL?
0
Да кто его знает зачем они так делают)) Мы в одном проекте тоже активно используем схему protobuf для валидации данных из API, но лишь потому что мы им же и пакуем для передачи следующему компоненту системы. Своеобразное http api -> protobuf api. Зачем это делает Medium не знаю.
0
Protobuf немного более гибкий чем Json. Например в нем есть разные типы данных чисел. (int, float, int32). Можешь задать тип сообщения, то есть все сообщения будут соответствовать определенному формату.

Плюс, ты описываешь какие-то данные и protobuf сгенерит набор классов для конкретного языка для работы с этими данными. В Json тебе придется самому писать эти классы. Ну а потом уже можно эти сообщения уже гонять по сети в компактном формате или класть в кеш, или даже сохранять в базу данных.
0
Я не уверен, что вы поняли о чем речь. Речь о JSON схеме. А она как раз позволяет описывать данные гораздо более точно. Скажем, для Int задавать граничные значения. Ну и конечно существуют библиотеки, чтобы генерить классы из схемы или и json.
+2
Подумал, что еще за черти «medium», никогда о них не слышал, потом глянул сайт и понял, что последний год читаю статьи оттуда.
0

Тоже столкнулись с проблемой DynamoDB и "горячих" ключей и поставили Редис перед ним, полет нормальный :)

0

Сдаётся мне, постановка кеша перед Бд является вполне распространённым решением этой проблемы :)

+1

Тут дело в том, что DDB позициноруется как "очено быстрое" KV хранилище, что по факту оказывается немного не так, и если среднее время доступа довольно приемлимо (~20ms у нас), то пики очень раздражают.


Хотя они сейчас придумали DAX, кеш перед DDB, но стоимость у него нехилая

Only those users with full accounts are able to leave comments., please.