Комментарии 7
Архитектура ну совсем так себе. Вы своим пакетом заставляете людей использовать ini файлы для конфигурации… один вопрос — зачем??? (хотел написать иначе, но не хочу показаться грубым)
Зачем делать так:
Когда можно сделать:
Где params какая-то публичная структура из пакета mggo.
Как задумка — интересная, но реализация — жуть… все прибито гвоздями, и хттп хендлеры, и sql (pg), и кэш безразмерный с очень специфической реализацией…
Зачем делать так:
mggo.Run(rout, "./config.ini")
Когда можно сделать:
mggo.Run(rout, params)
Где params какая-то публичная структура из пакета mggo.
Как задумка — интересная, но реализация — жуть… все прибито гвоздями, и хттп хендлеры, и sql (pg), и кэш безразмерный с очень специфической реализацией…
+2
Спасибо за совет! Вы правы, через публичную структуру будет намного удобнее. Будем дорабатывать…
0
туда же:
1) добавить go.mod
2) добавить абстракцию для обработки запросов http (может я хочу работать с fasthttp)
3) добавить абстракцию для обработки sql (может я не хочу pq, а хочу тот же sqlite3, mysql, оракл (ну вдруг я извращенец)).
4) реализация кэша очень замудренная, советую посмотреть готовые in-app пакеты, коих на гитхабе несколько популярных для go. Текущий кэш крайне опасен для памяти.
5) опять же абстракцию и для кэша не мешало бы, у вас там мелькает редис, но есть и другие, а логика плюс минус та же.
6) код явно не проверялся на race, а их там будет. Используется много мапов, но только в кэше есть mutex (код кэша явно откуда то взят, либо гайды либо либы другие).
7) GetAPIResult — там есть рефлект, довольно тяжелая вещь, если она вызывается на каждый запрос — то зря. Нагрузку данная реализация не выдержит.
8) логирование — жутко страшное (я про реализацию), плюс еще и в файлы… никакой настройки снаружи…
это то, что просится прям сразу сходу при первом взгляде. Особо не смотрел, возможно там еще есть где кривости.
1) добавить go.mod
2) добавить абстракцию для обработки запросов http (может я хочу работать с fasthttp)
3) добавить абстракцию для обработки sql (может я не хочу pq, а хочу тот же sqlite3, mysql, оракл (ну вдруг я извращенец)).
4) реализация кэша очень замудренная, советую посмотреть готовые in-app пакеты, коих на гитхабе несколько популярных для go. Текущий кэш крайне опасен для памяти.
5) опять же абстракцию и для кэша не мешало бы, у вас там мелькает редис, но есть и другие, а логика плюс минус та же.
6) код явно не проверялся на race, а их там будет. Используется много мапов, но только в кэше есть mutex (код кэша явно откуда то взят, либо гайды либо либы другие).
7) GetAPIResult — там есть рефлект, довольно тяжелая вещь, если она вызывается на каждый запрос — то зря. Нагрузку данная реализация не выдержит.
8) логирование — жутко страшное (я про реализацию), плюс еще и в файлы… никакой настройки снаружи…
это то, что просится прям сразу сходу при первом взгляде. Особо не смотрел, возможно там еще есть где кривости.
+2
Веб-фреймфорк — это наверное все же шаблонизатор удобный и интересный какой-никакой должен быть. Я вот лелею надежду xslt прикрутить без прибивания гвоздями xsltproc. Чтобы можно было отдавать контент и указывать во что его превращать, выбирая нужный шаблон. ХТМЛ или в ПДФ например.
А уж как роутинг сделать (есть valyala/fasthttprouter например) и ORM с кешем проложить прослойкой между базой и остальным — это я думаю не самая главная проблема.
Но в любом случае, тема затронута интересная. Спасибо.
А уж как роутинг сделать (есть valyala/fasthttprouter например) и ORM с кешем проложить прослойкой между базой и остальным — это я думаю не самая главная проблема.
Но в любом случае, тема затронута интересная. Спасибо.
0
очень необычный язык.
чем он необычный?
+1
Всё описанное является довольно типичной попыткой без раздумья скопипастить в воркфлоу на Go «лучшие практики» из asp.net. В той или иной степени это весьма распространённый синдром новичка (я не имею ввиду отравляющий газ), и лечится практикой в течении 2-3 месяцев продуктивного кодирования.
Слушайте, худшее, что можно написать на Go, это MVC фреймворк. В Go уже есть 2 фреймворка — gRPC и go-swagger. Там решены большинство задач, типичных для Go приложения, которые следует решать с помощью фреймворков. Например, декларативное описание сервисов в части маршрутизации, валидации моделей апи и авторизации. У Вас этого нет. А вот мельница, с которой Вы воюете, гоферов не интересует от слова вообще — утверждаю это на примере фреймвоков buffalo и beego, которые в сообществе неофициально признаны полным говном.
Слушайте, худшее, что можно написать на Go, это MVC фреймворк. В Go уже есть 2 фреймворка — gRPC и go-swagger. Там решены большинство задач, типичных для Go приложения, которые следует решать с помощью фреймворков. Например, декларативное описание сервисов в части маршрутизации, валидации моделей апи и авторизации. У Вас этого нет. А вот мельница, с которой Вы воюете, гоферов не интересует от слова вообще — утверждаю это на примере фреймвоков buffalo и beego, которые в сообществе неофициально признаны полным говном.
+1
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Знакомство с Go и Mggo Framework