Pull to refresh
18
Karma
0
Rating
Sergei Golitsyn @deft31

Software Engineer

gRPC vs REST, что выбрать для нового сервера?

У нас на C# возникли с ним проблемы. И необходимо было писать свои велосипеды.

10 приниципов разработки на Java

Я сталкивался в одном из своих проектов с либой которая работала до Java 7. И таких либ было несколько. Из за этого миграция на Java 8 была очень сильно затруднена и болезненна.

Награды в играх. Вариант backend реализации

Спасибо за информацию. Приму к сведению. Данный вариант в целом предусматривает возможность отражать это. Как раз можно показывать конфигурацию награды, которую заводят ГД.

Награды в играх. Вариант backend реализации

А что не так с конфигурацией наград? Мы задаем и меняем именно конфигурацию награды. Это скажем так справочник.

Награды в играх. Вариант backend реализации

От чего же? Почему она должна быть атомарной? множество юзеров могут взять один конфиг награды и получить собственную награду рассчитанную контент генератором.

gRPC сервер с нуля

А есть шансы с вами по сотрудничать над стартером?

gRPC сервер с нуля

Если посмотреть выше и прочитать, что написано в статье. То я указываю какую зависимость использую и говорю что в восторге от этого стартера.

gRPC сервер с нуля

Ээм да. Я и не говорил, что не использую его.

gRPC сервер с нуля

"а не рукоблудство." - что вы подразумеваете под этим?

gRPC сервер с нуля

Воу оч круто, если запускается с ходу. Вы сделали просто топовую либу. У нас не у всех с ходу все работало. Хотел бы поучаствовать в этой либе, если есть шанс.

gRPC сервер с нуля

Будет круто если то что указано в офф доке этой либы запустится у вас сходу. Здесь больше приведен практический пример, что бы запустить все сходу с минимальным временем.

gRPC vs REST, что выбрать для нового сервера?

Для Java и C# все есть и работает чудестно.

gRPC vs REST, что выбрать для нового сервера?

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

gRPC vs REST, что выбрать для нового сервера?

Да, но тут скорее что бы заставить из коробки работать gRPC нужно потратить больше времени и сил. Хотя бы потому что туторов для REST намного больше и с ними чаще работаешь. В дальнейшей переспективе, вероятно выигрывает gRPC. Но думаю каждому свое.

gRPC vs REST, что выбрать для нового сервера?

Есть куски, взятые из документации, которые было сложно перефразировать.

По поводу скорости компрессии — вот, думаю этого достаточно? auth0.com/blog/beating-json-performance-with-protobuf

gRPC vs REST, что выбрать для нового сервера?

На самом деле если использовать рест по верх hhtp2 то gRPC изначально не будет быстрее, но вот достаточно подробный ответ:
> elective message compression. In gRPC a streaming RPC can decide to compress or not compress messages. For example, if you are streaming mixed text and images over a single stream (or really any mixed compressible content), you can turn off compression for the images. This saves you from compressing already compressed data which won't get any smaller, but will burn up your CPU.
First class load balancing. While not an improvement in point to point connections, gRPC can intelligently pick which backend to send traffic to. (this is a library feature, not a wire protocol feature). This means you can send your requests to the least loaded backend server without resorting to using a proxy. This is a latency win.
Heavily optimized. gRPC (the library) is under continuous benchmarks to ensure that there are no speed regressions. Those benchmarks are improving constantly. Again, this doesn't have anything to do with gRPC the protocol, but your program will be faster for having used gRPC.
As nfirvine said, you will see most of your performance improvement just from using Protobuf. While you could use proto with REST, it is very nicely integrated with gRPC. Technically, you could use JSON with gRPC, but most people don't want to pay the performance cost after getting used to protos.

gRPC vs REST, что выбрать для нового сервера?

grpc.io/blog/mobile-benchmarks

> We found that regardless of the serialization/deserialization method used for protobuf, it was consistently about 3x faster for serializing than JSON. For deserialization, JSON is actually a bit faster for small messages (<1kb), around 1.5x, but for larger messages (>15kb) protobuf is 2x faster. For gzipped JSON, protobuf is well over 5x faster in serialization, regardless of size. For deserialization, both are about the same at small messages, but protobuf is about 3x faster for larger messages.

И это только про сериализацию.

Как я познавал ci/cd, Гитхаб экшены

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

— В гитлабе не экшены
Вот ссылочка. Там экшены:
docs.gitlab.com/ee////////user/project/quick_actions.html

Найти подстроку в строке

была опечатка, поправил. спасибо.
1

Information

Rating
Does not participate
Date of birth
Registered
Activity