DZ
Ррребяят, а кто-нибудь мерил на сколько медленнее go webasm нативного go? или может статью видели. Чёт не нахожу
tiny go медленней, а нативный го слишком большой
Size: a a a
2020 March 13
ЗА
tiny go медленней, а нативный го слишком большой
это, конечно, логично, но интересны хотя бы примерные цифры, в пару раз, в десятки раз, сотни, тысячи
/
Есть пример хорошей проверенной структуры rest API приложения на основе gin/echo/..., но не MVC, а максимально идиоматическое решение?
Если вы задаете такой вопрос то посмотрите сначала на это:
https://github.com/gopherschool/http-rest-api
а потом на это:
https://github.com/golang-standards/project-layout
https://github.com/gopherschool/http-rest-api
а потом на это:
https://github.com/golang-standards/project-layout
/
Но боюсь это сейчас приведет к религиозной войне)
D
/dev/null
Если вы задаете такой вопрос то посмотрите сначала на это:
https://github.com/gopherschool/http-rest-api
а потом на это:
https://github.com/golang-standards/project-layout
https://github.com/gopherschool/http-rest-api
а потом на это:
https://github.com/golang-standards/project-layout
второе к вопросу архитектуры веб приложения слабо применимо, а в первом напрягает наличие пакета
model, что уже наводит сомнения насчет идиоматичности/
Ну вы тогда наверное понимаете как нужно писать идиоматическое REST API
ЗА
второе к вопросу архитектуры веб приложения слабо применимо, а в первом напрягает наличие пакета
model, что уже наводит сомнения насчет идиоматичностиа чем пакет model напрягает?
/
И да, то что вы используете в качестве обертки над http server не относится к "идиоматическому REST API"
ЗА
а чем пакет model напрягает?
я без агрессии, реально интересно
D
а чем пакет model напрягает?
Хранить все модели/типы в одном пакете отдельно от логики - антипаттерн, иначе он должен называться иначе
/
фреймворки всего лишь инструменты
ЕО
А что тогда относится? Голый http?
REST это про то какой либой вы делаете обработку запросов, а про архитектуру самого апи