Состоялся релиз PostgREST 9.0.0, отдельно работающего веб-сервера с реализацией легкой надстройки к СУБД PostgreSQL, транслирующей объекты из существующей базы данных в RESTful API. Вместо отражения реляционных данных в объекты (ORM) в PostgREST представления создаются прямо в базе данных. На стороне БД также выполняется сериализация ответов JSON, проверка данных и авторизация. Производительности системы достаточно для обработки до 2000 запросов в секунду на типовом сервере. Код проекта написан на языке Haskell и распространяется по лицензии MIT...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=56245
Тут недавно некий анинми сильно бугуртил по поводу использования в СУБД REST-API вместо бинарных протоколов. Главные аргументы были в стили - "это неправильно, ибо ящетаю что это неправильно! Воть!".
Добавлю от себя что я очень рад, что мечты сбываются.
Например для мобильных приложениях этот ваш рест совсем никуда не уперся. Ну и дальше по списку.
почему?
Самое простое зачем мобильнику тратить время не сериализацию, перегонять этот ваш текст в числа и наоборот, когда например на андроиде, приложение может сразу получить бинарный джавовый объект с любой абстракцией хоть с массивом хоть с чертом лысым? Этим же можно решить вопрос сессий, в отличии от стейтлесс реста. Да много всего можно делать но для среднего хомячка это все конечно сложно.
сессии - бессмысленная трата ресурсом по всем фронтам
Сессия -- это абстракция и не имеет прямого отношения к ресурсам.
Сериализация -- это очень субъектное понятие по трудозатратам и, в большинстве случаев, затраты несущественные.
А вот как обеспечить прозрачное и безопасное взаимодействие с базой через рест без прокладок в виде ОРМ модели, я так и не понял.
> затраты несущественные.Да, на уровне сложности hello, world.
>> затраты несущественные.
> Да, на уровне сложности hello, world.На любом уровне. Если у Вас возникли проблемы с затратами на сериализацию при реализации комплекса ПО, то Вам бы грамотности подучиться. Гонять данные, без надобности, по сети всегда было признаком малограмотного вайтишника.
> Сессия -- это абстракция и не имеет прямого отношения к ресурсам.
> Сериализация -- это очень субъектное понятие по трудозатратам и, в большинстве случаев,
> затраты несущественные.
> А вот как обеспечить прозрачное и безопасное взаимодействие с базой через рест
> без прокладок в виде ОРМ модели, я так и не понял.сессия - это архитектурное решение, предпологающее хранение состояния, из-за этого хранения состояния вытекают все затраты, от памяти до распределенных серверов сессий
т.е. это всегда +N, если можно без сессий сделать тоже самое, то сессии - не нужно
>сессии - бессмысленная трата ресурсом по всем фронтам- для однопользовательской БД, да. А при наличии нескольких пользователей с разными планами запросов сессии дают умное кэширование данных - кастомное для клиента
>получить бинарный джавовый объект...через REST
>получить бинарный джавовый объектПервый получает бинарный объект, второй использует анонимную функцию, результат ну вы сами догадались.
А другие платформы, а партнеры, сразу видно чувак апи не видал рабочего.
Бинарный джавовый объект - это бэкдор.
Сюрпрайз - мир не ограничивается смартфончиком в твоём кармане.
Ещё совсем немного, и пориджи изобретут веб сервер и пхп.Назовут Rest Service
и
Active JSON Transformation Language.
И как это натянуть например на существующий ORM например в той же джанге. Да никак. Это я вообще к чему? Да к тому что это очередное ненужно.
Если кому-то (тебе) не нужно, это ещё не означает, что и остальным не нужно. Л - логика. И вообще, тебя кто-то заставляет пользоваться, что ли?
У Оракла через REST работает Golden Gate, к примеру. Здесь, видимо, тоже что-то такое можно соорудить при необходимости.
У Оракла через REST работает APEX
У Оракла есть Oracle REST Data Services. Это коммерческий аналог сабжа.
Oracle REST Data Services разве коммерческий?
> Oracle REST Data Services разве коммерческий?коммерческий, но бесплатный. пока у оракла опять пятка не зачешется.
алсо you must comply with all U.S. and applicable export control and economic sanctions laws or else
>И как это натянуть например на существующий ORM например в той же джангеДостаточно взять простой советский...
Пока не добавят балансировщик нагрузки и мастер мастер репликацию для бд - в прод не пригодно.
Балансировщик - любой существующий для http. Условно делай апстримы в nginx и балансируй себе.
Репликация - уже давно есть в постгресе.
Глупо было бы им переизобретать велосипед...
Репликация, nginx — это всё и есть велосипеды. Так и вижу как ты пойдешь к директору банка и начнешь рассказывать как ты делаешь балансировку, через бесплатную тулзу, которую пишет васян, которая не дает никаких гарантий ни для чего. Про репликацию, когда у тебя основная нагрузка это запись. А директор тебе выдаст волчий билет и отправит на биржу труда.
Директор банка, как правило, прислушивается к своему начальнику отдела автоматизации (или как там называется эта должность том в конкретном банке). Если для этого специалиста nginx (или haproxy, или varnish) - это васянопродукт, то я хотел бы знать название этого банка, чтобы держаться от него подальше.
(Собственно говоря, я знаю один такой банк - самый крупный в РФ, претендующий на более чем полуторавековую историю, который завязался на проприетарное ПО зарубежного производителя и теперь вынужден подчиняться ограничениям, которые ему выставляет поставщик ПО - например, этот банк не может работать в Крыму. Так я забрал из него все деньги, которые там по привычке держали родители).
Да я тебя даже скажу он называется Сбербанк. Дело правда было давно лет 10 назад.
Ни один вменяемый банк не будет работать в Крыму и никакого отношения к IT, проприетарному ПО и тд, это не имеет, вся эта кухня с Крымом это для ура-поцреотов, а нам про open source, пожалуйста.
Ваш анализ вменяемости очень полезен..для 6 палаты... а к ИТ "вся эта кухня" имеет самое непосредственное отношение. Потому что количество отраслей на которые будет распространятся действие последней версии экспортных ограничений США - будет только расти.
Слышали новость? Под санкции попал МФТИ :) Давай до свиданья Оракл в МФТИ, давай досвидос амигос винда в МФТИ. Давай пока VmVware в МФТИ... Я не знаю, может они и не пользовались ничем этим... Но и не будут :) И это хорошо.
Потому что будет создано свое. Что поднимет квалификация своих программистов, а не заплатит денюжку забугорным.
> И это хорошо.
> Потому что будет создано свое. Что поднимет квалификация своих программистов, а не заплатит денюжку забугорным.Проходили уже в истории "будет создано своё". Шо, опять? (с)
Кагбэ, вполне работающий подход - брать чужое и на его основе делать своё.
> Кагбэ, вполне работающий подход - брать чужое и на его основе делать
> своё.ни с чем не совместимое, а если совместимое, то остальному миру не нужное, и тд и тп. Работающий подход, понимаю. Если в этом самоцель (тоесть даже не пресловутое "импортозамещение"), то это нечто.
А что, для королёвской Р7 нужно было сохранить совместимость с боеголовками для фонбрауновской V-2? Или корабли Петра Первого должны были сохранить совместимость с голландскими лебёдками для якорных цепей?
А сейчас что ты работаешь не на боеголовке а на персональном ПК. И кушаешь ты хлеб а не боеголовку. Think about it.
Ну, от хлеба требуется только совместимость с моим желудком. А что до вычтехники - очень хороший пример, кстати - после перехода в СССР на архитектуру IBM развитие вычтехники в СССР почти полностью прекратилось, потому что любая самостоятельная разработка могла обернуться потерей совместимости со будущими разработками самой IBM. Так что лучше на совместимость сразу забить.
Копирование IBM было единственным нормальным решением в той ситуации. Продолжать местечковую мышиную возню не было никакого смысла.
> Копирование IBM было единственным нормальным решением в той ситуации. Продолжать местечковую
> мышиную возню не было никакого смысла.Всё зависит от поставленных целей.
Себе нужно быть нужным, а не остальному миру.
Более того, остальному миру особенно ненужно чтобы у вас был совместимый конкуретнвй продукт, вот ненужно. Подумойте почему. Может просвятитесь.
Просто ты будешь меньше кушать. Никто ничего создавать не будет. В Северной Корее что-то ничего своего не сделали.
> Ни один вменяемый банк не будет работать в КрымуХы... а можете озвучить свои критерии "вменяемости"?
>> Ни один вменяемый банк не будет работать в Крыму
> Хы... а можете озвучить свои критерии "вменяемости"?Санкции. Те, на которые вам пофиг, а банкам (присутствующим на международном финансовом рынке) нет.
>>> Ни один вменяемый банк не будет работать в Крыму
>> Хы... а можете озвучить свои критерии "вменяемости"?
> Санкции. Те, на которые вам пофиг, а банкам (присутствующим на международном финансовом
> рынке) нет.единственно верный и адекватный комментарий, доступ к финансовым инструментам и финансовым рынкам стран, наложившим определенные санкции, - вот определяющий фактор, а ПО - это капля в море в структуре затрат, которые понесет банк
поэтому работать в Крыму может позволить себе только банк-прокладка, и то есть такое понятие как вторичность санкций, когда попадает вся цепочка
в общем для тех буйных сверху с овердохрена любопытства существуют услуги недешевых лоеров международников (~300-500 баксов в час раньше было за консультацию, что на сегодня не интересовался), объяснят все на пальцах, но за ваши кровные так сказать...
Пц, "адекваты" подобрались... Признак адекватности для них - нахождение под топором.
> Пц, "адекваты" подобрались... Признак адекватности для них - нахождение под топором.так что ж ты лезешь под гильотину, если на заборе написано "осторожно под напряжением"
куда и под какую гильотину лез МФТИ?
Завязывай с телеком это не твоё.
Внезапно, у этого крупнейшего банка внутри очень много nginx.
Но сюрприз это не балансировщик перед постгресом, который пытается изображать толи мастера толи маргариту.
> Репликация, nginx — это всё и есть велосипеды. Так и вижу как
> ты пойдешь к директору банка и начнешь рассказывать как ты делаешь
> балансировку, через бесплатную тулзу, которую пишет васян, которая не дает
> никаких гарантий ни для чего. Про репликацию, когда у тебя основная
> нагрузка это запись. А директор тебе выдаст волчий билет и
> отправит на биржу труда.Никто не сделает репликацию постгреса лучше чем сами разработчики постгреса. И очень мало продуктов могут достойно конкурировать с nginx по балансировке http трафика. По твоим словам я точно понимаю что ты не директор банка и далек от ИТ. Еще больше удивлю, что самые сложные, что самые нагруженные трафиком проекты - это не банки. Не устраивает бесплатно, то у обоих продуктов есть платная версия.
А если директор будет нести ахинею не разбираясь в теме, то я сам уйду к более адекватному работодателю. К счастью на рынке дефицит квалифицированных специалистов и это не будет проблемой. А тебе я бы не советовал со старта переходить на личности - это сильно понижает.Расскажи лучше как бы выглядели не велосипеды в твоем понимании - мы либо рассмеемся, либо ты откроешь многим глаза на то как должна строится инфраструктура;)
Сразу открою секрет банк будет использовать нормальные базы данных, которые сами всё умеют, а не городить велосипеды непонятно из чего.
Ну, пафосно конечно но глупо.Назовите пожалуйста хотябы две таких СУБД не попадающих под санкции?
Тебя что кроме банка никуда больше не берут? Почему у тебя техническая дискуссия сводится к "банки используют" и "банки не используют"?
Ладно открою еще 1 секрет, что каждая база нормальная для определенного круга задач и та платная база на которую ты намекаешь, не для всех задач будет оптимальным решением. Также открою еще 1 секрет, что ту базу на которую ты намекаешь банки используют только потому что многие готовые решения для твоих банков заточенны под нее, а не потому что она лучшая для всех задач.
Также напомню что изначально дискуссия началась тем что тебя уведомили что полноценные репликация и балансировка для данного решения доступны. Но, возможно, просто вы настолько привыкшие к тому что "консультанты платных продуктов" думают за вас и просто говорят как надо сделать для конкретной задачи, что у вас сформировалось "тунельное мышление". Других объяснений вашей реакции на начало типичной технической дискуссии у меня нет.
К тому же, товарищу наверное будет любопытно узнать, что под капотом тех решений "которые банки используют" зачастую находятся просто опенсорсные программы, или нечто купленное у нонеймов и слегка допиленное...
К директору банка прийдет чувак в костюме который расскажет про импортозамещение, sla, ROI....
И директор банка никогда не узнает что там на самом деле под капотом- всего лишь nginx и штатная репликация постгреса.
Кстати мастер-мастер репликация в постгресе есть, и доступна в исходных кодах...
Директор выразить свою глубочайшую заинтересованность и продолжит использовать продукт, который работает. А не тот который ему скажут.
Интересно, видел ли кто-нибудь из участников дискуссии директора банка.
> Репликация - уже давно есть в постгресеПожалуйста, озвучьте проверенное решение. По тому, что я знаю, мастер-мастер репликации не существует из коробки в PostgreSQL. Есть коммерческое решение от EnterpriseDB. Называется Postgres-BDR (или ещё: "Always on").
При этом все комментарии про отсутствие решения мастер-мастер и успешность такой архитектуры я склонен объяснять тем, что утверждающий такое человек, имел опыт с MySQL.
Вообще MySQL, поправьте если я не прав, это единственная реляционная база данных умеющая такое из коробки. И для этого есть причины. Главная - очень сложно алгоритмически разрабатывать такое решение. Оракл, например, не захотел идти по этому пути и тоже не умеет мастер-мастер. Но это же не конец света. Кому надо, могут использовать GG или писать свои решения.
Я вообще считаю, что мастер-мастер на _уровне базы данных_ - это зло. И выставлять это, как какой-то недостаток, считаю это неоправданным требованием.
>>>Оракл, например, не захотел идти по этому пути и тоже не умеет мастер-мастер.вот щас оракл раку стало очень обидно
С чего бы то это ему было обидно? Оракл RAC - это разделяемое хранилище с блочной репликацией. Там нет такой сущности как "самостоятельная нода работающая как мастер или чтото иное". Там все ноды- работают с одной версией БД, которая лежит на распределенном блочном устройстве.
сорьки, я было подумал, что pq dbr это мастер/мастер синхронная репликация, порадовался - ну хоть какое-то подобие рака.так-то рак кластер, как вы правильно написали, с шаред хранилищем, и ровно по этой же причине - в репликации блочных устройств не нуждается.
блочное устройство- это не идиома для жесткого диска как вы очевидно думаете. блочное устройство в отличие от символьного - это такая сущность интерфейс которого общается с внешним миром посредством блоков а не символов.
блок- ключевое понятие в оракле, на нем все держится. и процесс репликации данных в RAC тоже происходит блоками.
То самое шаред хранилище - вполне себе блочное устройство. которое реплицируется.
> То самое шаред хранилище - вполне себе блочное устройство. которое реплицируется.куда?
там всё хуже - поскольку хранилище общее, то в принципе к одному блоку ломиться транзакции на разных нодах, из-за этого лезут какие-то глобальные блокировки, производительность падает в пол в таких случаях. Борьба с напастью - это работать с одним набором данных на одной ноде, с другим - на другой, например на уровне партиций. Но какой-то набор данных будет общим всегда. Но вот чем тут может быть лучше мультимастер с репликацией ума не приложу - дублирование стораджа под хранение одних и тех же данных на разных нодах, более высокий трафик между нодами при сохранении необходимости как-то синхронизировать встречные изменения данных, сделанные на разных мастерах.
Про мастер-мастер репликацию никто не упоминал ранее. Классическая репликация (master-slave) есть из коробки и она более чем проверенная.Если говорить о мастер-мастер для постгреса, то родной реализации нету, но есть несколько сторонних большинство из которых с открытым кодом в том числе есть и открытые сорцы старых версий BDR.
Если говорить о мастер-мастер в целом для РСУБД, то любая из существующих реализаций имеет существенные нюансы либо изначально заявленные ограничения.
MySQL действительно умеет мастер-мастер из коробки, но есть сценарии при которых такая репликация может создать проблемы, т.э. имеет нюансы которые нужно учитывать. Из-за чего в реальности на продакшене это до сих пор не популярное решение и там где используется нужно учитывать эти нюансы архитектурно. Оракл, кстати также официально умеет в мастер-мастер и нюансы там примерно такие же как и MySQL.
Но по мне, если очень-очень нужен master-master и нельзя использовать другие архитектурные решения и есть возможность использовать любую БД, то вместо учитывания нюансов о которых никто явно не пишет и сидения на пороховой бочке, лучше использовать решения которые изначально создавались как распределенные базы данных. Т.э. условная Cassandra имеет изначальные ограничения по синтаксису и возможностям, но зато очень хорошо масштабируется и решает конфликты в сравнении с классическими master-master любой РСУБД. А так то именно мультимастер не всегда нужен и почти всегда можно разделить базу на несколько отдельных, шардировать, селекты делать со слейвов и прочие решение в зависимости от проблемы которую нам нужно решить и это будет более прогнозируемо чем мультимастер.
> Оракл, кстати также официально умеет в мастер-мастер и нюансы там примерно такие же как и MySQLнет, извините, но всё же не умеет. RAC - это не мастер-мастер данных, а только инстанса.
извиняю, но я не имел ввиду RAC. Я имел ввиду - https://docs.oracle.com/cd/B28359_01/server.111/b28326/repma...
Точно, вспомнил теперь. Есть такая штука у Оракла. Когда-то в конце 90-х на модемных линиях её использовали. И это не оценочное суждение, просто факт.
Мне вот интересно, что такое "типовой сервер", который в заметке упоминается? И сколько на "типовом сервере" можно выжать запросов в секунду на родном протоколе при прочих равных?
Обернуть простую базу данных в dotnet + entity framework - пустяковое дело.А для сложных случаев, эту штуковину применять не стану.
Я частный разработчик, разрабатываю веб и программные решения.Использую в продакшене -- как бакенд собственной корп CRM, но так же разрабатываю клиентские решения на базе бакенда на Postgrest.
Postgrest ускорил мою работу в 10 раз, при этом избавив от типичных ошибок и вечного "написания одного и того же ORM кода".Не умеете готовить -- ну брыжьте слюной в комментариях дальше :)
Покажи пример чем это лучше обычного орб
Сходите посмотрите как работает APEX на оракле.
Вот то что делают для постгреса- это нечто подобное. И это правильно.
это настолько абстрактно, что даже толсто
...рассосались рубцы, вес пришел в норму, прекратилось облысение и кошка стала ходить строго в лоток?
Не только! Всего за 999999.99$ для адаптации постгрест под нынешнюю инфраструктуру и 999999999.99$ за миграцию избавили нас не только от проблем на стороне сервера, но ещё и от крыс, мышей, лягушек, блох, клопов, вшей, проверяющих из ОБЭПа, налоговой, военкома для сынка гендира, санкций за работу в Крыму, открыли третий глаз, расшили чакры, дали фуриёку для звания короля шаманов, помогли найти и прочитать сисечный свиток из коробки медаки, вся наша компания прямо таки сплотилась во едином порыве и бухгалтер стал кишечником, менеджер - мускулами, а сисадмин - клоакой! Рекомндую, закажите только сейчас у авторизованного тентакля и получите кучу удовольствия в подарок!
Это что, типа минимизация бэкэнда? вплоть до его обнуления? и обнуления необходимости в бэкэнд-щиках? Другого смысла никакого вроде не просматривается...
Как бы экономическая суть всего IT - обнулить лишние траты. Какой тут смысл ещё может быть? :)
Хм, тогда всё равно все бэк-эндовые заморочки во фронт-энд уйдут, а по сети будет больше данных гоняться. Небезопасно, медленно, больше нагрузка на клиентов, врядли сильно дешевле - фронт-эндер будет как два-в-одном.
> все бэк-эндовые заморочкине уловил сути. Например что?
1. За счёт чего траффика станет больше?
2. В чём именно выражается небезопасность?
3. Почему это должно быть медленно и нагружать фронт?
Поставил себе, поигрался. Вполне годный инструмент, свои задачи выполняет хорошо.
Я так давно не видел простого CRUD приложения, что не представляю зачем такое решение нужно.Что бы все делать на front? А есть ли тогда какие-то механизмы защиты и валидации?
Обычно во многих фреймворка есть что-то готовое, где получить crud можно одной командой. Но это надо в 10% на небольшие таблицы справочники.
Что бы упростить backend... Это больше актуально для микросервисов, когда отпадает необходимость делать свой api-сервис для взаимодействия с базой. В микросервисах не принято делать что б каждый сервис стучался напрямую в базу в силу многих причин, для этого либо пишут свой api-сервис либо используют что-то готовое типа этого сабжа.
Вспоминая одну старую дискуссию...
А потом оверхед от всех этих г***прослоек становится таким, что танцорам начинает latency в TCP мешать...
У всех разные задачи и разные решения для них. Кто-то до сих пор деплоит раз в 2 года монолит вручную по фтп и ему норм - никаких латенси, но в таких изначальных условиях он может себе это позволить, а кто-то не может...
Угу, смузи скиснет.
конкретно сабж даёт дополнительную задержку в норме меньше 10mshttp_req_duration..............: avg=2.4ms min=476.37µs med=1.42ms max=39.1ms p(90)=5.23ms p(95)=7.47ms
> конкретно сабж даёт дополнительную задержку в норме меньше 10msНехренаж себе.
Видел я эти ваши микросервисы, когда носители черепов с кашеподным продуктом http и json с API путают. И в итоге получается, да, вот это самое, как его, когда сотня юзеров вешает датабейс сервис параллельно получая таймауты от редиса.Ну ничего, теперь датабейс сервис не нужен потому что рест сразу в постри интегрирован.
Это настолько тупо, что у меня нет слов, в мире нет слов для называния этого имбецилизма.
Это не называемая тупость.
> Что бы все делать на front? А есть ли тогда какие-то механизмы защиты и валидации?Наоборот. Вся валидация делается схемой базы данных. Т.е. тупо инсерт не пройдет. А фронтэнду нужно только красиво ошибку обработать.
Суть в том, что валидация делается максимально близко к хранению данных. Фактически в транзакции и никак обойти это не получится. Второй уровень валидации - на фронтэнде тоже можно делать но это уже опционально.
То что вы говорите - это антипаттерн и так делать нельзя. Сабж изначально делался как коробочный апи-сервер для микросервисов для работы с базой и об этом недвузначно намекает картинка в самой новости...
Если не сложно, развейте мысль, пожалуйста.Я картинку вставил для общей наглядности из источника, который вообще об DOA был (https://news.ycombinator.com/item?id=29209365). В новости она - это моя спекуляция на тему архитектур и возможного применения.
Если так, то тогда и фраза "Архитектурно PostgREST подталкивает к данно-ориентированной архитектуре (Data-Oriented Architecture), где микросервисы не сохраняют состояния сами, а используют для этого единым доступом к данным (Data Access Layer)." также является своего рода манипуляцией.
Относитесь к моему высказыванию больше как к субъективному мнению еще одного параноика)
Данный сабж не использую на проектах и свое мнение формировал исключительно из новости и своего понимания того как нужно. Оказывается многие действительно используют и в сценариях описанных выше в качестве альтернативы GraphQL и основные возможности для работы в качестве публичного апи сервера у него действительно есть. Отсюда получается что немного погорячился в выводах, хотя странно что никто меня не исправил)
>Т.е. тупо инсерт не пройдет.
>и никак обойти это не получитсяХа, а ты смешной!
Предлагаешь логику бэкенда делать на триггерах и хранимках? Ну удачи.
Это ответ на Oracle-овый ORDS но только на Haskel?
Такое себе, скажу я вам.
А почему нет?
Я бы и сам с удовольствием использовал Оракл, но он же много-много денег стоит. Но есть позитивный момент - Oracle JET бесплатный и как раз заточен на REST. Сабж должен хорошо подойти в качестве бэкэнда.
Странно это все, для какой-то узкой микросервисной задачи, даже картинку не положить
А вы sql запросами картинки часто кладете?
Вот, только что на коленке накидал и проверил. Хоть картинки, хоть что:
create table api_v5.bloblo (id uuid, le integer, blo bytea);create or replace function api_v5.blobhere(bytea) returns void language sql as $$
insert into api_v5.bloblo (le,blo) values ((select length($1)),$1);
$$;curl -X POST -H "Authorization: Bearer eyXXX" -H "Content-type: application/octet-stream" -v -d '@demo.bin' 'https://api.XXX.de/v5/rpc/blobhere'
select encode(blo, 'escape') from api_v5.bloblo;
Не знал про это чудо, спасибо за наводку."Код проекта написан на языке Haskell..."
Вот уж кому-то действительно надоело писать ORM для каждой задачи, выбор Haskell наводит на мысль что ребята делают проект с умом и душой, делая код простым и гибким.Для Big Data это конечно не предназначается, но должно весьма нехило упростить жизнь разработчикам обычных бекендов.
Только меня вот это смутило?
"Производительности системы достаточно для обработки до 2000 запросов в секунду на типовом сервере"
Или штo там за типовой сервер, Raspberry Pi 1A штoле?
vendor_id : GenuineIntel
cpu family : 6
model : 60
model name : Intel Core Processor (Haswell, no TSX)
stepping : 1
microcode : 0x1
cpu MHz : 2399.996запустил $ k6-v0.35.0-linux-amd64/k6 run -d 10s -u 20 ./test-pgrst-local.js
2 ядра под 100% + 50% сам k6
Результат:
http_reqs......................: 18457 1844.250269/s
Благодарю.Сфейспалмил.
Закопать и не выкапывать.
> Или штo там за типовой сервер, Raspberry Pi 1A штoле?Вы вот шутите, а у нас тут финансовая микросервисная система на 300 юзерах укакивается.
И жива она на проде только потому, что фронтенд всё тротлит. Ну и там мощности aws побольше конечно чем на тесте.
2000 запросов это вообще ничего. Будет хотябы 200000 в секунду, будет разговор.
я так понимаю 1000 запросов на ядровсего лишь 200 ядер нужно для указанных вами требований
Т.е. 1 арм-процессора хватит? Там как раз около 200 ядер.
арм - кака.
тут нужен Cerebras.
И ведро смузи. На один рылодень )
> 2000 запросов это вообще ничего. Будет хотябы 200000 в секунду, будет разговор.Для жава микросервисов 2000 это космос.
Не, ну тут задача-то вообще тривиальная.
Как они смогли???
Я не очень понял как здесь транзакции запускать/откатывать?Допустим, мне нужно сделать 3 инсерта, и если хоть один не прошёл - развернуть всё взад.
Написать хранимку, HTTP is a stateless protocol.
Транзакции - это слишком сложно :D
RESTful API позволит работать с документами, а не базой напрямую. Да, маппинг делается 1:1 к таблицам на все операции CRUD. С вьюхами другое дело - маппинг на CREATE и UPDATE уже автоматически не сделаешь. Поэтому для них нужно отдельно писать before INSERT и before CREATE триггеры.
Таким образом 3 инсерта в разные таблицы пройдут полностью или откатятся все. PostgREST не избавит от необходимости писать такую логику. Она всегда кастомная исходя из бизнес логики. Но во всех других решениях нужно делать то же самое, только здесь это удобней из-за PL/PgSQL. Лаконичней не придумали ещё.
А как версионировать и обновлять туда-обратно триггеры с хранимками? Я просто как-то раз пробовал это через alembic-миграции делать, но удовольствие это было, скажу откровенно, ниже среднего.
Я вижу, вы разбираетесь в сабже. Тогда для чего все эти усложнения?Почему нужно использовать это, а не работать с базой напрямую?
Другими словами - где и в чём выгода?
разбираюсь в том плане, что использую это, дапричины, наверное, разные могут быть. В моём случае (1) нужно было провести черту между фронтэнд и бэкэнд разработчиками и, соответственно, OpenAPI спецификация стала единственным местом обсуждения и договора между ними; (2) фронтэнд разработчики без вопросов умеют работать с RESTful API; ну и (3) то, что единый API используется и UI, и программно сервисами которые вообще неподконтрольно пишутся пользователями платформы SaaS.
*before INSERT и before *UPDATE* конечно же
На прошлой работе рассматривали сабж, как вариант для вытаскивания БД в REST, но по некоторым требованиям не зашло. В итоге я за несколько месяцев запилил более-менее аналог, но на других технологиях.
А что не получилось? поделитесь, если не секрет.Я стал использовать сабж именно, чтоб самому каждый раз не писать такие прослойки. И пока не столкнулся с ситуацией, чтоб что-то не получилось реализовать из задуманного.
Нужна была схема строго в OpenAPI 3.0, а PostgREST умеет только в Swagger 2.0 (по крайней мере на тот момент умел только в нее), плюс возможность дорабатывать что-то, если требования поменяются, а я оказался единственным человеком в команде, кто хоть как-то знаком с хаскеллем (ну то есть на уровне HelloWorld), и не стал бы брать на себя ответственность, что любую фичу там смогу запилить. Плюс это все должно было уйти на сертификацию во ФСТЭК, и как там отнеслись бы к тому же хаскеллю - ХЗ.
В итоге сделали аналог на JavaEE.
думаю вы всё правильно сделали.меня отсутствие prepared statements смущает больше всего: https://docs.subzero.cloud/postgrest-plus/#prepared-statements
коммерческий PostgREST+ всего 250EUR/год стоит. Для моего SaaS это копейки. Есть вариант и исходники у них купить этого решения, если очень надо.
Ого, то что обычная версия генерит не prepared statement я тогда даже не заметил. Такое точно бы на сертификации завернули.
> меня отсутствие prepared statements смущает больше всегоСказанное выше неверно, PostgREST генерирует подготовленные операторы для всех запросов, начиная с версии 8.0.0.
См. Https://postgrest.org/en/v8.0/configuration.html#db-prepared....
Также актуально https://github.com/PostgREST/postgrest/issues/1789#issuecomm...
Corrected link(had a "." at the end):https://postgrest.org/en/v8.0/configuration.html#db-prepared...
спасибо за уточненияособенно вторая ссылка раскрыла ситуацию совсем под другим углом. Я почему-то думал что steve-chavez и есть проект subZero, а он оказывается в supabase
не сочтите за рекламу:
https://supabase.com/ - очень круто сделали (и ещё делают). Я просто что-то похожее, но для внутреннего использования строил, поэтому и понравился их подход.
Объясните любителю вебмамаке , я правильно понимаю сабж предоставляет просто api для фронта?
А как тогда интересно происходит авторизация обычных пользователей микросервиса?
Для авторизации на микросервисе нужна отдельная база для доступа к api фронта? Или сабж также предоставляет возможность авторизации обычных пользователх к доступа к базе?
Это не первый такой инструмент, например есть hasura https://hasura.io/graphql/database/postgresql/ которая вообще генерирует graphql, что намного удобнее обычного rest. Фактически такие инструменты просто переносят бизнес логику и логику авторизации на сторону своих инструментов авто генерации API. Т.е. вместо кода мы занимаемся написанием конфигурационных файлов + sql запросов местами. Проблема таких инструментов включая hasura и PostgREST, что как бы они не пиарились их хватает только для очень простых проектов и то не всегда.Это потому что в реальном приложении код очень сложен, часто нужна интеграция с различными инструментами (очереди, kafka и пр.), нужна генерации разных вариантов сообщений (маппинг, сложная логика), нужен пре- и пост- обработка ответов/запросов и многое другое.
Вот когда начинаешь углубляться в документацию и примеры, то выходит что в рекламках все красиво, а как доходит до практики, то функционала не хватает даже у самых развитых платных вариантов, не то что у слабо поддерживаемых новых проектов.
Стоит еще отметить что такие средства как фрэймворк+ORM для базы фактически выполняют работу кэша (локальные транзакции на уровне приложения), оптимизатора и балансировщика. И вероятность того что все это реализовано на хорошем уровне в авто генераторе REST стремится к нулю. Плюс современные среды разработки заточены на статический анализ кода и чтобы подготовить разработку на новых еще сырых инструментах как PostgREST нужны месяцы в лучшем случае, и это очень важно т.к. писать код в блокнотике никто на реальном проекте будет.
Проще говоря, как сидели на старых проверенных фреймворках так все и будут. А штуки типа PostgREST в обозримом будущем для блогов, сайтов визиток и ОЧЕНЬ простых магазинов.
Мне просто интересен стал вопрос безопастности в случае доступа к api обычных пользователей. Но если сабж предназначается для совсем блого-новости сервисов, то тогда подход более менее понятен.
У меня назрел вопрос: 2000 запросов в секунду - разве это много?
смотря каких и смотря на каком сервере. если это одноядерная 2 гиговая балалайка на хецнере, то покатит
все было хорошо до слова хаскель и стало понятно почему так мало запросов