YJ
Cube.js - где-то уже видел эту вакансию, но тут вроде не бывала
Most of Cube.js software is open- source...
Most of Cube.js software is open- source...
Size: a a a
2020 August 14
DI
у них будет скоро второй продукт, уже коммерческий (на базе этого, разумеется) :)
DI
Cube.js - где-то уже видел эту вакансию, но тут вроде не бывала
Most of Cube.js software is open- source...
Most of Cube.js software is open- source...
возможно я писала уже сюда, но не по DataBase позиции
YJ
возможно я писала уже сюда, но не по DataBase позиции
из их "пула" было
https://t.me/rust_jobs/7727
https://t.me/rust_jobs/7727
DI
даа, это была стартовая позиция, сейчас это две разные)
С++/Rust отдельно, Node.js отдельно
С++/Rust отдельно, Node.js отдельно
YJ
главный по "кошечкам"
Pavel Tiunov, Co-founder & CTO, выпускник Бауманки 2010 года
Pavel Tiunov, Co-founder & CTO, выпускник Бауманки 2010 года
DI
ага, вы по ссылочке в ликендин посмотрели или знакомы лично?)
YJ
ага, вы по ссылочке в ликендин посмотрели или знакомы лично?)
да, по ссылкам, лично нет
M
ну ... да) только зачем крутому спецу тратить 20 минут, если он понимает, что это джунская зп
Ну понял я даже на Джуна не подошёл
M
Чё бывает
M
скажу честно, что в супер технических подробностях тут не подскажу.
я так поняла, что ни одна из существующих БД им не подошла, ребята планируют разработать свою, уже продумывают архитектуру.
их продукт — это фреймворк для разработки аналитических данных, используется для анализа триллионов точек данных со временем отклика менее секунды.
я так поняла, что ни одна из существующих БД им не подошла, ребята планируют разработать свою, уже продумывают архитектуру.
их продукт — это фреймворк для разработки аналитических данных, используется для анализа триллионов точек данных со временем отклика менее секунды.
Позовите за деньги чела с постгреса про он вам вкорячет на любой спид
AD
Думаю, если бы им нужен был архитектор для выбора технологий для решения их бизнес-задач, то они так бы и написали.
K
Всем привет, есть задача довольно простая по сути:
Проблема:
48 процессов NodeJS работают через PM2, и отправляют на разные сервера http запросы, запросы формируются пачками
Пачки на разные сервера API, и из-за устройства event-loop происходит блокирование при работе с http запросами
Также каждый запрос формирует по дескриптору на соединение, что уменьшает производительность keep-alive соединений ( тут скорее подозрение )
Решение:
По GRPC протоколу на Rust сервер будет приходить пачка Http/https запросов ( подготовленные body, url, headers ) , в ответ по GRPC протоколу стрима будет отсылаться по мере поступления ответы, их никак обрабатывать не надо(отдать в чистом виде статус, body,
Запросы могут быть как и http так и https
Почему GRPC а не Http - потому что по http нельзя отдавать по частям ответы, только одной пачкой
Post - body + url + headers, Get - url + headers
В каждом запросе также параметр requestId для идентификации
Работать многопоточно и многоканально
Ищу по большей части хорошего растомана который решит данную задачу, при этом сам хочу наблюдать как пишется код ( ибо изучаю Rust и недоконца понимаю некоторые вещи )
Заплачу! Писать в личку с ценой и пометкой
#Rustbulkhttp
Проблема:
48 процессов NodeJS работают через PM2, и отправляют на разные сервера http запросы, запросы формируются пачками
Пачки на разные сервера API, и из-за устройства event-loop происходит блокирование при работе с http запросами
Также каждый запрос формирует по дескриптору на соединение, что уменьшает производительность keep-alive соединений ( тут скорее подозрение )
Решение:
По GRPC протоколу на Rust сервер будет приходить пачка Http/https запросов ( подготовленные body, url, headers ) , в ответ по GRPC протоколу стрима будет отсылаться по мере поступления ответы, их никак обрабатывать не надо(отдать в чистом виде статус, body,
Запросы могут быть как и http так и https
Почему GRPC а не Http - потому что по http нельзя отдавать по частям ответы, только одной пачкой
Post - body + url + headers, Get - url + headers
В каждом запросе также параметр requestId для идентификации
Работать многопоточно и многоканально
Ищу по большей части хорошего растомана который решит данную задачу, при этом сам хочу наблюдать как пишется код ( ибо изучаю Rust и недоконца понимаю некоторые вещи )
Заплачу! Писать в личку с ценой и пометкой
#Rustbulkhttp
PM
Всем привет, есть задача довольно простая по сути:
Проблема:
48 процессов NodeJS работают через PM2, и отправляют на разные сервера http запросы, запросы формируются пачками
Пачки на разные сервера API, и из-за устройства event-loop происходит блокирование при работе с http запросами
Также каждый запрос формирует по дескриптору на соединение, что уменьшает производительность keep-alive соединений ( тут скорее подозрение )
Решение:
По GRPC протоколу на Rust сервер будет приходить пачка Http/https запросов ( подготовленные body, url, headers ) , в ответ по GRPC протоколу стрима будет отсылаться по мере поступления ответы, их никак обрабатывать не надо(отдать в чистом виде статус, body,
Запросы могут быть как и http так и https
Почему GRPC а не Http - потому что по http нельзя отдавать по частям ответы, только одной пачкой
Post - body + url + headers, Get - url + headers
В каждом запросе также параметр requestId для идентификации
Работать многопоточно и многоканально
Ищу по большей части хорошего растомана который решит данную задачу, при этом сам хочу наблюдать как пишется код ( ибо изучаю Rust и недоконца понимаю некоторые вещи )
Заплачу! Писать в личку с ценой и пометкой
#Rustbulkhttp
Проблема:
48 процессов NodeJS работают через PM2, и отправляют на разные сервера http запросы, запросы формируются пачками
Пачки на разные сервера API, и из-за устройства event-loop происходит блокирование при работе с http запросами
Также каждый запрос формирует по дескриптору на соединение, что уменьшает производительность keep-alive соединений ( тут скорее подозрение )
Решение:
По GRPC протоколу на Rust сервер будет приходить пачка Http/https запросов ( подготовленные body, url, headers ) , в ответ по GRPC протоколу стрима будет отсылаться по мере поступления ответы, их никак обрабатывать не надо(отдать в чистом виде статус, body,
Запросы могут быть как и http так и https
Почему GRPC а не Http - потому что по http нельзя отдавать по частям ответы, только одной пачкой
Post - body + url + headers, Get - url + headers
В каждом запросе также параметр requestId для идентификации
Работать многопоточно и многоканально
Ищу по большей части хорошего растомана который решит данную задачу, при этом сам хочу наблюдать как пишется код ( ибо изучаю Rust и недоконца понимаю некоторые вещи )
Заплачу! Писать в личку с ценой и пометкой
#Rustbulkhttp
тебе быстрее и продуктивнее будет самому с этим разобраться, попутно спрашивая в чате/чатах вопросы, чем вот так "обучаться".
K
тебе быстрее и продуктивнее будет самому с этим разобраться, попутно спрашивая в чате/чатах вопросы, чем вот так "обучаться".
у меня одновременная любовь и война с borrow чекером )
K
Времени больше намного убью
Ct
Времени больше намного убью
Если ты хочешь научиться, то это не "убитое" время.
K
Если ты хочешь научиться, то это не "убитое" время.
да, но если человек будет подкованный , я буду лучше понимать почему нужно сделать именно "этим" методом, а не другим
K
а так, метод тыка, войны и боли
PM
да, но если человек будет подкованный , я буду лучше понимать почему нужно сделать именно "этим" методом, а не другим
https://github.com/tokio-rs/tokio/blob/master/examples/proxy.rs
1. смотри
2. т.к. grpc нет - за работу возьму на 10% меньше
3. карту скидывать ? 😃
1. смотри
2. т.к. grpc нет - за работу возьму на 10% меньше
3. карту скидывать ? 😃
