LINUX.ORG.RU

Какие есть реальные преимущества написания Rest API на Java?

 ,


1

1

Всем привет! Напишите по своему опыту, какие есть реальные преимущества и недостатки создания Rest API на Spring + Hibernate? Интересует в сравнении с Go/NodeJS/Python/Php. Например, в каких случаях API лучше пилить именно на Java?

Либо я глупый, либо вопрос. Унылый CRUD с поддержкой авторизации, ролей и всего вот этого вот делается за 15 минут даже без спринга, на голом томкате; в го, пыхе и ноде, полагаю, ещё быстрее. На чём написан остальной код и подо что есть настроенный контейнер - на том и пиши 0_о

izzholtik ★★★ ()

А что конкретно ты хочешь услышать? Я сомневаюсь, что найдётся много лорчан, которые разрабатывали что-то серьёзно и на спринге, и, допустим, на джанге, и на ларавеле.

Я писал синхронные Web API, асинхронные до и после asyncio на Python. Небольшую апишку на Go и чуть чуть раширял готовую на PHP. Умею в JS и немного ноду, но апишки на пих не писал, Java когда-то учил, но писал на ней довольно мало (спринг в глаза не видел, но вполне представляю что это).

Могу потеоретизировать.

WitcherGeralt ★★ ()

Сам процесс на жабе и на пыхе (в условиях любого фреймворка типа симфони) мало отличается. А вот далее с пыхом ты огребаешь все радости скриптоты и динамической типизации (для последнего пыха менее актуально). Думаю остальные тоже на начальном этапе мало отличаются.

А зачем тебе рест? Он же убогий.

ya-betmen ★★★★★ ()
Ответ на: комментарий от izzholtik

Я спрашиваю не на чем мне писать, конкретной задачи нет. Просто знаю, что кто-то пилит API на java - вот и интересно стало, в каких случаях использовать java было бы предпочтительнее и почему.

dimuska139 ★★ ()
Ответ на: комментарий от WitcherGeralt

На этом всем и я пишу, и Java тоже учил когда-то еще в универе) Хотелось просто услышать java-разрабов :)

dimuska139 ★★ ()
  1. возможность затянуть разработку
  2. спихнуть ответственность на тех кто это пишет
  3. вынудить поддерживать этот кусок дерьма вместо того чтобы переписать его
quester ★★ ()
Ответ на: комментарий от izzholtik

Либо я глупый, либо вопрос. Унылый CRUD с поддержкой авторизации, ролей и всего вот этого вот делается за 15 минут даже без спринга

Тут разговор про REST, это значит нужно из URI парсить путь, аргументы, параметры, их нужно валидировать, плюс еще библиотеки для сериализации/десераиализации JSON. Короче без spring получится свой фреймворк начиная с DispatcherServlet. Тут недостаток в количестве не проверенного кода, который никто кроме автора поддерживать не захочет.

Aber ★★★★★ ()
Ответ на: комментарий от quester

Не юзал. Сейчас прочитал, но не понял: а в чем профит? Особого удобства не вижу, в реальных проектах тоже ни разу не натыкался. Для той же Django последние коммиты в библиотеку для JSON-RPC были аж 7 лет (вот еще - 5 лет назад) назад, что намекает на то, что это как бы не развивается особо и не востребовано.

dimuska139 ★★ ()
Ответ на: комментарий от dimuska139

Шо ты как ребёнок? На Java пишут REST только тогда, когда уже куча кода написана на JAVA, в других случаях джаву и не берут - она жрёт как не в себя. Java и Ruby - самые жрущие по памяти языки, так java хоть работает быстро

menangen ★★★★★ ()
Ответ на: комментарий от dimuska139

Если ты в одну морду пишешь - java не для тебя. Для тебя python, node, Go, Dart, php. Тут вопрос о времени разработки стоит обширно, и скриптота с кучей либ на первом месте всегда

menangen ★★★★★ ()

Go

Убогий многословный язык без исключений. На Java писать код раза в 3 быстрей.

NodeJS/Python/Php

Если речь о JS, нетипизированная параша, на Java писать код раз в 5 быстрей и в 10 раз меньше багов.

Legioner ★★★★★ ()
Ответ на: комментарий от dimuska139

Эти фичи в питон привносит джанга, а пых он в принципе такой, но ларавель выводит это на новый уровень.

WitcherGeralt ★★ ()
Ответ на: комментарий от Legioner

На Java писать код раза в 3 быстрей

Чушь несусветная, эта многословная дрянь и «быстрее» в одном предложении могут быть только в анекдоте.

WitcherGeralt ★★ ()
Последнее исправление: WitcherGeralt (всего исправлений: 1)
Ответ на: комментарий от dimuska139

То, что удобно. Увы, но REST — это как тот глобус. Всем хорош, но вот реальная сова на него не натягивается.

Miguel ★★★★★ ()
Ответ на: комментарий от WitcherGeralt

Многословность не мешает писать код быстрей. Скорей наоборот, помогает. Ты же не машинистка, которая ограничена скоростью клавиатуры.

Legioner ★★★★★ ()
Ответ на: комментарий от Miguel

Под словом REST обычно понимают любой HTTP/JSON API. На измышления Филдинга давно всем плевать.

Legioner ★★★★★ ()
Ответ на: комментарий от WitcherGeralt

само набирание текста во времени разработки составляет наверное тысячную процента и на стоимость разработки не влияет. синтаксис, вербозность - это никак вообще не влияет.

anonymous ()
Ответ на: комментарий от stasolog

Да хотя бы простейшая фича — вычитать файл целиком, она есть в стандартной библиотеке, и это дофига приятно.

Представь стандартную библиотку питона, только без мусора, лучше вдвое и с байтами. Это Go.

WitcherGeralt ★★ ()
Ответ на: комментарий от anonymous

Ещё как влияет. На этом просто не хочется писать. Не зря есть Scala, Groovy, Kotlin и ещё хренова туча херни запиленной лишь бы не писать на джаве.

WitcherGeralt ★★ ()
Ответ на: комментарий от WitcherGeralt
String FileUtils.readFileToString(file)
byte[] FileUtils.toByteArray(file)

А чем они хуже?


Но я посмотрел, действительно неплохо. Правда Java сильна сторонними библиотеками как мне видится.

stasolog ()
Последнее исправление: stasolog (всего исправлений: 1)
Ответ на: комментарий от WitcherGeralt

Ещё как влияет.

Очевидно, на джаве ты не писал никогда. Если бы писал хоть немного, то так бы не говорил.

Тем более, понятно, что ты не писал проектов больше хелловорлда, которые реально работают и поддерживаются.

Ты кукаретик-пустослов, мнение которого ничего не значит.

anonymous ()
Ответ на: комментарий от WitcherGeralt

язык без исключений не может быть лаконичным.

тем более го вообще уродец без дженериков и нормальной поддержки многопоточности (в чем Java лидер).

anonymous ()
Ответ на: комментарий от dimuska139

Не только. Но в джаве они действительно киллер.

rupert ★★★★★ ()
Ответ на: комментарий от anonymous

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

Siborgium ★★★★ ()
Ответ на: комментарий от dimuska139

В 80% случаях ты будешь городить на ресте убогую замену рпц. Поэтому есть смысл сразу брать рпц.

ya-betmen ★★★★★ ()
Ответ на: комментарий от WitcherGeralt

Не зря есть Scala, Groovy, Kotlin и ещё хренова туча херни запиленной рабами лишь бы не работать

fixed

а ты, со своим «опытом» на жабе, лучше бы молчал

anonymous ()

По теме: лучше чем Java full stack ты в 2020 году не найдешь. Спросишь «чем лучше?» – по всем направлениям лучше чем всё остальное. И если кодер попадет под трамвай, следующего можно найти на улице за 5 минут.

Правда с hibernate я бы поспорил. Оно часто overkill и не нужно как и всякие Spring Data JPA. Проще писать запросы в базу руками с jdbc template на перевес. Так понятней и «магии» в коде нет.

anonymous ()
Ответ на: комментарий от WitcherGeralt

Насчёт говноязыка согласен, не надо его использовать. Но Go ещё хуже.

Miguel ★★★★★ ()

Я не писал REST на всем прочем, но все прозаично, жабадевелоперов много, аноним прав что можно спокойно найти людей на рынке труда с опытом.
Еще spring фреймворк не сильно ломает обратную совместимость, например там все еще есть старый способ создания транзакций программным способом, все классы на месте, хотя последний раз я им пользовался наверное лет 10 назад.

У JVM есть технические преимущества перед Python и Node - настоящий мультипоток, со всеми примитивами и подходами для работы с разделенными ресурсами.

Из всего перечисленного у тебя только Go и Java статически типизированные языки, для многих это решающий фактор при выборе инструмента.

Aber ★★★★★ ()
Ответ на: комментарий от Miguel

Сторонник удобства и поддерживаемости. Когда у тебя в проекте десятки зависимостей, а у каждой зависимости ещё чёрт знает сколько, ты уже не то, что не можешь гарантировать, что проект у тебя через год-два соберётся, ты уже сейчас не контролируешь то, что у тебя в прод попадает. Удачи со 100% покрытием при таком подходе.

WitcherGeralt ★★ ()
Ответ на: комментарий от anonymous

Так наоборот, я не сторонник. Но когда у тебя огромное количество сторонних библиотек используется, тебе хочешь, ни хочешь, а придётся всё это покрывать тестами. Рано или поздно оно сломается, и без тестов ты об этом узнаешь, скорее всего, уже раскатив это на прод.

WitcherGeralt ★★ ()
Последнее исправление: WitcherGeralt (всего исправлений: 1)
Ответ на: комментарий от WitcherGeralt

Типичный Goшник detected.

В нормальных проектах не делают импорт по гитхаб-урлу. Там в проект добавляют конкретные версии. Которые через год-два не поменяются.

Ну и, да, 100% покрытие — это такой символ веры из мира динамически и слабо типизированных языков, где без тестов невозможно даже понять, должно ли то, что твой сосед написал, работать в твоём случае.

Miguel ★★★★★ ()
Ответ на: комментарий от anonymous

Не знаю, что такое «jdbc template», но, исходя из моего опыта разработки на Php/Python/Go, могу сказать, что писать запросы в базу руками - то еще извращенство. Я не сторонник ORM, но квери-билдер и дата-гидратор (чтобы результаты запроса маппить на объекты), как минимум, нужны. Потому в противном случае при куче фильтров придется конкатенировать строку с запросом руками.

dimuska139 ★★ ()
Ответ на: комментарий от Aber

Причём Go с его interface {} слабо подходит на роль статически типизированного.

Miguel ★★★★★ ()
Ответ на: комментарий от menangen

Php и Python разве сильно меньше жрут? Goшка, понятное, дело меньше - это ясно.

dimuska139 ★★ ()
Ответ на: комментарий от Miguel

Что мешает зафиксировать версию в go.mod?

это такой символ веры из мира динамически и слабо типизированных языков

Ну как бы те же проекты на Java активно покрывают тестами. В ней слабая типизация?

dimuska139 ★★ ()
Ответ на: комментарий от WitcherGeralt

Ты, кажется, не понимаешь что такое «сторонние библиотеки» в java мире. Это очень хорошо оттестенный код. Сделан он для того, чтобы не строили велосипедов. Через maven я обновляю версии примерно раз в 2 года, ито хз зачем. Просто чтобы up to date было. Итак все работает.

Например: покрывать тестами какой-нибудь apache poi нет надобности. У него огромное комьюнити и багов там почти нет.

anonymous ()
Ответ на: комментарий от menangen

Если ты в одну морду пишешь - java не для тебя. Для тебя python, node, Go, Dart, php.

Если с Python и Php ясно, то на Go разве проще в одну морду писать? Там же многие вещи реально приходится вручную делать. Фреймворков типа Laravel/Django и т.п. нет, только Gin/Gonic по сути. Если в Django подключил либу - и есть у твоей APIшки JWT (даже с возможностью добавлять токены в черный список) тут же, то на Go это все пилишь руками. Да, есть для Gin/Gonic либа, но она реализует JWT одним токеном без возможности рефреша. То есть по сути половину этой задачи пилишь руками. Так ли уж проще в одну морду?

dimuska139 ★★ ()
Ответ на: комментарий от dimuska139

Не знаю, что такое «jdbc template»

Так погугли.

но квери-билдер и дата-гидратор (чтобы результаты запроса маппить на объекты), как минимум, нужны

Там много магии. У меня 50% работы это рапорты. В типичном рапорте задействованы примерно все таблицы, что есть. Попробуй это на ORM напиши. Получится такой медленный динозавр-франкинштейн, что рапорта клиенты будут по 30 минут ждать.

Потому в противном случае при куче фильтров придется конкатенировать строку с запросом руками.

Так и делаю. Зато знаю что именно делает запрос, потому что сам его пишу и оптимизирую.

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.