Я сталкивался в одном из своих проектов с либой которая работала до Java 7. И таких либ было несколько. Из за этого миграция на Java 8 была очень сильно затруднена и болезненна.
Спасибо за информацию. Приму к сведению. Данный вариант в целом предусматривает возможность отражать это. Как раз можно показывать конфигурацию награды, которую заводят ГД.
От чего же? Почему она должна быть атомарной? множество юзеров могут взять один конфиг награды и получить собственную награду рассчитанную контент генератором.
Воу оч круто, если запускается с ходу. Вы сделали просто топовую либу. У нас не у всех с ходу все работало. Хотел бы поучаствовать в этой либе, если есть шанс.
Будет круто если то что указано в офф доке этой либы запустится у вас сходу. Здесь больше приведен практический пример, что бы запустить все сходу с минимальным временем.
Да, но тут скорее что бы заставить из коробки работать gRPC нужно потратить больше времени и сил. Хотя бы потому что туторов для REST намного больше и с ними чаще работаешь. В дальнейшей переспективе, вероятно выигрывает gRPC. Но думаю каждому свое.
На самом деле если использовать рест по верх 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.
> 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.
Как подготовиться к собеседованию, чтобы получить нужную должность?
Обычно разработчик это "кодер"
gRPC vs REST, что выбрать для нового сервера?
У нас на C# возникли с ним проблемы. И необходимо было писать свои велосипеды.
10 приниципов разработки на Java
Я сталкивался в одном из своих проектов с либой которая работала до Java 7. И таких либ было несколько. Из за этого миграция на Java 8 была очень сильно затруднена и болезненна.
Награды в играх. Вариант backend реализации
Спасибо за информацию. Приму к сведению. Данный вариант в целом предусматривает возможность отражать это. Как раз можно показывать конфигурацию награды, которую заводят ГД.
Награды в играх. Вариант backend реализации
А что не так с конфигурацией наград? Мы задаем и меняем именно конфигурацию награды. Это скажем так справочник.
Награды в играх. Вариант backend реализации
От чего же? Почему она должна быть атомарной? множество юзеров могут взять один конфиг награды и получить собственную награду рассчитанную контент генератором.
gRPC сервер с нуля
А есть шансы с вами по сотрудничать над стартером?
gRPC сервер с нуля
Если посмотреть выше и прочитать, что написано в статье. То я указываю какую зависимость использую и говорю что в восторге от этого стартера.
gRPC сервер с нуля
Ээм да. Я и не говорил, что не использую его.
gRPC сервер с нуля
"а не рукоблудство." - что вы подразумеваете под этим?
gRPC сервер с нуля
Воу оч круто, если запускается с ходу. Вы сделали просто топовую либу. У нас не у всех с ходу все работало. Хотел бы поучаствовать в этой либе, если есть шанс.
gRPC сервер с нуля
Будет круто если то что указано в офф доке этой либы запустится у вас сходу. Здесь больше приведен практический пример, что бы запустить все сходу с минимальным временем.
gRPC vs REST, что выбрать для нового сервера?
gRPC vs REST, что выбрать для нового сервера?
gRPC vs REST, что выбрать для нового сервера?
gRPC vs REST, что выбрать для нового сервера?
По поводу скорости компрессии — вот, думаю этого достаточно? auth0.com/blog/beating-json-performance-with-protobuf
gRPC vs REST, что выбрать для нового сервера?
> 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, что выбрать для нового сервера?
> 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
Найти подстроку в строке