Каркас приложения REST на Spring

спасибо, сделаю

ещё логирование делай более информативнее. строка в логе должна сразу объяснять что произошло и при какой операции. при ситуации сейчас, у тебя будет NPE, а где оно появилось, при каких условиях и при какой операции (запросе, ситуации) информации нет. а про ломбок ты зря. например тот же @Slf4j даёт тебе сразу log , в которой хранится такой же логгер, что ты руками для каждого класса писал. там комментарии/ревью не удаётся оставить. странная конструкция у тебя

public ResponseEntity<Article> createArticle(Article article) {
        try {
            Article _article = repository.save(new Article(article.getTitle(), article.getExcerpt(),
                    article.getContent(), article.isActive(), article.getUser()));

1) начинать с "_" такое себе, чистый код это не подразумевает. с JS пришёл? почему бы не использовать savedArticle или findedArticle? 2) у тебя же пришёл Article зачем ты на его базе пытаешься создать новый? вот так тоже нехорошо

Map<String, Object> response = new HashMap<>();
response.put("articles", articles);
response.put("currentPage", pagedArticles.getNumber());
response.put("totalItems", pagedArticles.getTotalElements());
response.put("totalPages", pagedArticles.getTotalPages());
return new ResponseEntity<>(response, HttpStatus.OK);

сделай DTO класс с нужными тебя полями, и используй его для ответа.

большое спасибо за советы, все посмотрю

errør, что-то я не догоняю, как тут сделать DTO, DTO - это класс, а мне нужна Map?

всё верно. делаешь dto класс. погугли про dto слои

а обязательно использовать библиотеку-маппер, или можно вручную? Или вручную это дурной тон?

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

Нашёл пример приложения на Spring В принципе ничего особенного, но есть примеры тестов и форки. В презентации опять упоминается AOP при логировании, но в проекте я почему-то не нашёл @Aspect. P.S. в форке есть для логирования вызовов репозиториев, зачем я не понял. Ещё используются модули, а чем они вообще хороши ?

Что ты имеешь в виду под модулями?

Модули https://habr.com/ru/post/499872/

И ещё мне нравится ломбок. Он очень простой и практически не требует изучения. Избавишься от кучи бойлерплейта, рекомендую.

Ещё рекомендую конфигурационный файл писать в yaml формате. Это как properties, только проще. У тебя сейчас:

spring.datasource.url=jdbc:postgresql://127.0.0.1:5432/springapp
spring.datasource.username=springapp
spring.datasource.password=springapp
spring.datasource.driver-class-name=org.postgresql.Driver

А вот yaml:

spring:
    datasource:
        url: jdbc:postgresql://127.0.0.1:5432/springapp
        username: springapp
        password: springapp
        driver-class-name: org.postgresql.Driver

Намного приятней и чище. Конфиги можно вот здесь почитать: https://docs.spring.io/spring-boot/docs/current/reference/html/application-properties.html

И я бы не стал csrf отключать. Конечно его все любят отключать по умолчанию, но я бы всё-таки настроил, а не отключал бы. Работать с ним довольно просто, я настроил его вот так:

http
                .cors().and()
                .csrf()
                .csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse())
                .ignoringAntMatchers(loginUrl);

на cors не обращай внимания. Собственно это вроде бы вся настройка, если ничего не забыл. login и logout я сделал post, а не get, как обычно делают. Благодаря этому csrf сработает, если злоумышленник попытается заставить тебя выйти из аккаунта.

спасибо большое за советы, все учту (кроме ломбока :) )

А почему ломбок не любишь?

не хочется к нему привязываться, те же дата классы появились

Хм, что за дата классы? Ну на самом деле я бы не сказал, что ломбок как-то вредит скиллу. Геттеры и сеттеры писать - это в IDEA всё равно делается автоматически, а вот код засоряется. К тому же ломбок не решает все проблемы и иногда руками конструкторы писать всё-таки придётся. Плюс очень хорошо ускоряется рефакторинг. Например, тебе надо два новых поля к классу добавить, сам посчитай: написать два геттера, написать два сеттера, обновить конструктор (если он один). Если у тебя ломбок, то ты просто добавляешь поля и всё, больше ничего делать не надо. Ну вот я полгода пользуюсь ломбоком, ничего, конструкторы и геттеры/сеттеры писать вроде не разучился, а работа быстрей идёт)

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

Я использую аннотацию @slf4j. Вроде ломкобовская. Там всё просто

Вроде ломкобовская Совершенно верно, ломбоковская

import lombok.extern.slf4j.Slf4j;

и там действительно все просто. Объявил аннотацию и фигачь.

"Хм, что за дата классы?" - https://habr.com/ru/post/482300/

Да, интересная штука. Но вряд ли буду использовать - для меня наследование имеет большое значение. Тут у ломбока гораздо больше вариативность.

попав на проект с java8/11 придётся переучиваться на ломбок)) не совсем понятно , зачем выбирать java 12+ для учебы, когда на проектах они оч редко используются

и это печально. когда осенью уже выйдет jdk 17 LTS...

"Избавишься от кучи бойлерплейта" - интересно почему в джава нет get; set;

попав на проект с java8/11 придётся переучиваться на ломбок))

ломбок используется мягко говоря, не на всех проектах из-за своих особенностей. Поэтому там как встретить крокодила на улице, 50 на 50, либо придется переучиваться, либо нет. Хотя на этапе учебы, ломбок разобрать стоит как по мне. Попадется ли он на проде или нет, вопрос второй.

не совсем понятно , зачем выбирать java 12+ для учебы, когда на проектах они оч редко используются

новички, сэр. Они не мыслят категориями продакшена, что использование любого инструмента должно быть обосновано. "Вижу последнюю версию - беру и использую" это подход юзера. Когда видишь в учебных проектах человека без опыта последние версии джавы, сразу становится много чего понятно :) Но что поделаешь, с опытом не рождаются, опыт и знания требуют времени начнут работать , увидят, глубже вникнут в процесс работы над версиями джавы, JCP, JEP, JSR и прочее, поймут, что на промежуточных версиях обкатываются фичи, и то что работает на 12 версии может не работать в 13, поскольку в 12-ой попробовали, не понравилось, в 13-й поменяли, а LTS версии это уже стабильные обкатанные сборки, а бизнес и продакшен и профессиональный подход требует именно стабильности , обкатанности, надежности. Это просто стадия обучения, если не все, то многие через нее проходили, когда нет ориентиров, как лучше и некому их дать, приходится формировать свою позицию по своих ощущениях. Потом подкорректируют и все будет ок.

// и это печально. когда осенью уже выйдет jdk 17 LTS... вот на 17 ЛТС уже будут переходить, поскольку это лтс. Да и почему печально? У тебя есть набор одежды, электроники, книг. Ты их обновляешь постоянно? Вышла новая редакция книги Шилдта которую прочитал, сразу купил новую или скачал и перечитал. Вышла новая версия телефона, сразу купил. Джинсы пару месяцев поносил, вышла коллекция новая ты сразу старые выбросил и купил новые. Ты посмотрел прикольный сериал, 5 сезонов по 20 серий. Через месяц вышло переиздание на БД с лучшим качеством, ты сразу сел и пересмотрел его снова? Для новых проектов, стандарт де-факто брать последнюю LTS версию. Для старых проектов, нужна аргументация почему переходить на новую версию? Это же приложение может быть на десятки тысяч классов, сотни фрейморвков, технологий, это монстрище, которое работает как часики. И тут нужно вырывать фундамент и переносить на другой. Зачем? Ради чего? Как это отобразиться на продукте? Ведь могут быть проблемы совместимости, полезть ошибки, а цену ошибок сам представь - там 50 млн долларов, там 100, там миллиард. Бизнес всегда будет задавать эти вопросы. Поэтому никто и никогде на больших проектах не дергается, когда выходят новые ВРЕМЕННЫЕ версии джавы. Да там новые фишки, но бизнес это не хипстеры, о новая фишечка , прикольно. Бизнес это ответственность, если джава управляет больницей, то самое главное, это не новая фишечка джавы, которая может выпилиться уже в следующем релизе, и на которую смысла нет переходить, а то, что приложение никого не убьет, и все пациенты получат максимально качественные услуги. Есть и исключения конечно, в ряде случаев, когда бизнес на 120% знает, что ему нужна именно эта версия джавы и что он получит взамен, тогда могут использоваться и промежуточные версии. Если ты лидер рынка, у тебя 200 млн клиентов, от твоего продукта зависят жизни, ты 100 раз подумаешь что тебе нужно и насколько. Понятно что есть тестировщики, стейджинги и прочие , но всякое бывает.

вот на 17 ЛТС уже будут переходить, поскольку это лтс. и то не сразу

Это из котлина что ли? Вообще я любопытную статью на хабре читал. Про котлин. Что-то вроде "почему котлин умрёт" или как-то так называлась. Интересные аргументы приводились. В частности, так как котлин в основном используется джавистами, то котлин вынужден постоянно следовать за джавой. Как бы если делать крутые фишки, то есть шанс потерять коммюнити джавы (из-за большой разницы в языках), а это большой риск для джетбрэйнс. А если ничего не менять, а просто следовать за джавой, то в чём тогда смысл котлина? Например та же котлиновская лакончиность с геттерами и сеттерами - у неё наверняка есть какие-то минусы, но менять уже что-то поздно. Тогда как в джаве достаточно подключить ломбок, который постоянно обновляется... Или не подключать ломбок. Во всяком случае, если в джаве появится какая-то неоднозначная штука, то джава не потеряет своё сообщество в одночасье. А вот котлин вполне может.

Меня в принципе восьмёрка абсолютно устраивает. Единственное, чем пользуюсь из новых версий: это свитч-выражения и текстовые литералы (очень удобно для написания SQL запросов в спринге)

"Для новых проектов, стандарт де-факто брать последнюю LTS версию." - так пока я допилю проектик, как раз LTS 17 и выйдет "попав на проект с java8/11 придётся переучиваться на ломбок))" - прочитав много статей про ломбок, я составил для себя мнение, что ломбок не всегда подходит, переучиваться там особо нечему, и тем более есть records, ну это вкусовщина, ant/maven/gradle, мне например больше composer нравится))) а логирование можно и через AOP в итоге додумать и заодно пощупать его. "не совсем понятно , зачем выбирать java 12+ для учебы, когда на проектах они... " - хочется пощупать свежее в проекте с нуля, а к старью всегда откатиться можно, who cares - my world, my rules))) В новой JDK же не только мелкие "ненужные" фичи, как кажется, а и множество оптимизаций производительности, и куча мелких фишек. Проектик мелкий, можно и альтернативную версию Lombok-8 edition запилить, с блекджеком и танцовщицами с Ломбоком и "старой доброй" 8-кой

нет, records не из котлина, они отличаются

Java 8 все ещё стандарт. Пока ещё стандарт Конечно если ты на работу собираешься устраиваться через 5 лет то тогда - может быть Java 8 и старье)

"Java 8 все ещё стандарт. Пока ещё стандарт Конечно если ты на работу собираешься устраиваться через 5 лет то тогда - может быть Java 8 и старье)" - А можно ведь и без таких комментариев обойтись, тем более я похожую ссылку уже скидывал выше - вот, и прекрасно знаю об этом? Обычно почему-то цепляются к мелочам, а по существу ничего))) предлагал-то тупо писать что-то вместе на спринге, не важно какая java/lombok, чтобы не изобретать велосипеды, могу помочь всем, что пока сам накопал, с тем же Swagger поначалу надо плясать с бубном, чтобы заработало)))

Согласен, мой комментарий был резковат, прошу прощения. Обиделся за восьмерку что ее старьем называют) А если по теме: то может быть будет хорошим вариантом оформить этот проект в виде цикла небольших статей? Что то вроде блога. Вот с того то ты начал, какие то интересные куски кода выкладывать, ссылки на материалы которые читал. И все кому интересно оставляли бы там комментарии и дополнения. А то боюсь тема быстро замылится на форуме.

цикл статей уже есть и не один

Это точно) Вряд ли можно написать лучше чем Алишев или Трегулов. Но если цель понять что то самому и систематизировать то почему и нет. Главное не заявлять что это авторский курс от нуля до гуру за 10 дней) П.С: В проекте я бы добавил: - джава доки; - слой DTO; - мапинг из DTO в Энтити и обратно.

Вряд ли можно написать лучше чем Алишев или Трегулов.
Но если цель понять что то самому и систематизировать то почему  и нет.

Да, +100500 Лучше чем Алишев и Трегулов можно и есть, и не один пример, а сотни :) Но с другой стороны, у контента всегда есть потребители, плюс, скольких бы замечательных лекторов бы мы потеряли, если бы каждый из них думал "та там А, Б или В уже так классно написали, куда мне". Для лектора, это систематизация и проработка материала, работа с людьми , кому интересно, для читателей это всегда точка зрения, а чем больше точек зрения тем лучше, коммюнити, у которых один лектор - это мертвый путь и тупик. Только там где много точек зрения, где много активных участников, каждый пытается по мере возможности привнести свое, вот это и запускает развитие. Но с другой стороны, это личный выбор автора, нет желания сегодня, завтра попробует.