darst, Впрочем я тоже считаю, что для создания вэб-приложения больше подходит подход чистой-архитектуры и ddd. Имхо на PHP, Python, Ruby гораздо легче и качественнее решать подобные задачи (писать вэб приложухи, блоги, сайты и т.д.) чем на Go. Он по идее для других целей создавался и хорошо справляется с микросервисами, низкоуровневыми утилитами и прочими нетривиальными задачами.
darst, Да в принципе разницы особой нет между вебсервером и низкоуровневыми утилитами. Архитектурные решение независимы, я считаю, от сути задачи. Если не убедил, вот пример кода официального golang сайта - https://github.com/golang/website В данном кейсе тоже отказываются "фрэймворкоподобной" структуры в пользу разделения логики на сущности.
Может ошибаюсь, конечно, но мне кажет для go чистая архитектура и ddd (как его обычно реализовывают) инородны (что то вроде пытаться писать как на java). В той же стандартной библиотеке вы не найдете разбиения на общие папки - models, controllers, utils, helpers и т.д. - все что относится к определенной сущности лежит в пакете этой сущности, т.е. есть пакет (папка) user, а в ней - model.go, helper.go, util.go без каких либо лишних вложение (порой пакеты в go могут содержать десятки файлов без вложенных дерикторий и это вроде как норм). В доке сказано, что на стандартную библиотеку нужно опираться как на пример "идеального" golang кода.
srdp11 Как упомянул - нужен stateful. Jwt токены налагают определенные трудности, например: непросто правильно реализовать их безопасное хранение, также для меня кажется критичной проблема невозможности отозвать эти токены без какого то черного списка.
Спасибо, но на сколько я знаю lazyload - это когда изображения скачиваются не все сразу, а постепенно (например при скролле). В данном случае это не подходит т.к. блок с аватарками сразу весь на экране пользователя и отложенная загрузка этих 2000 картинок будет заметна (эффект островков).
Василий Банников, по сути версия для заказчика - это то же самое ядро, только со специфичными доработками. вся суть моей идеи - реализовать независимость того функционала ядра, который будет у всех заказчиков. проект новый и первое время ядро будет активно дорабатывать, но при этом нужно поддерживать версии которые уже в продакшэне.
