Comments 10
Спасибо большое за ваш труд — добавил в Pocket — завтра в метро почитаю:)
Go — прекрасный язык, недавно написал на нем первое свое приложение (вот). Некоторые вещи по ходу вводили в ступор — но гугл помог:) Например — декодирование полученного JSON — приведение к типу вместо
Go — прекрасный язык, недавно написал на нем первое свое приложение (вот). Некоторые вещи по ходу вводили в ступор — но гугл помог:) Например — декодирование полученного JSON — приведение к типу вместо
json.loads в Python. Возможность кросс-компиляции подо все платформы с одним единственным бинарным файликом на выходе — это вообще восторг. Опять же на фоне Python с необходимостью тащить за собой virtualenv на продакшн. Надеюсь, скоро еще что-нибудь на нем напишу интересное. 
Спасибо! чем больше библиотек на Go тем лучше. Мы для работы с неструктурированными json данными написали вот такой хелпер gist.github.com/m0sth8/9498759, который позволяет получать данные по вот такому пути "/one/two/three[1]".
Хотя лично мне подход dependency injection нравится, многие разработчики Go негативно к нему относятся. Точнее даже не к нему, а к тому что в martini большую роль играет использование reflect. Если почитать статьи от Russ Cox и других, включая также официальные статьи по Go — там описывается, что reflect лучше использовать как можно реже.
Поэтому на мой вопрос в IRC на канале #go-nuts какой они предпочитают Go framework (а ведь есть же beego, martini, web.go, revel) рассказали, что предпочитают стандартный net/http или на крайний случай gorilla toolkit.
Другая проблема с которой можно столкнуться — версии пакетов. Хотя go get позволяет удобно выгружать сторонние packages, их версии не проверяются и для этого существует отдельное обсуждение и отдельные пакеты — например godep (запоминает commit sha, создает своего рода аналог virtualenv, но для Go приложений). Есть и множество других пакетных менеджеров, но в целом вопрос версий остается открытым.
P.S. Язык Go мне нравится, просто поделился мыслями после прочтения статьи. Автору спасибо!
Поэтому на мой вопрос в IRC на канале #go-nuts какой они предпочитают Go framework (а ведь есть же beego, martini, web.go, revel) рассказали, что предпочитают стандартный net/http или на крайний случай gorilla toolkit.
Другая проблема с которой можно столкнуться — версии пакетов. Хотя go get позволяет удобно выгружать сторонние packages, их версии не проверяются и для этого существует отдельное обсуждение и отдельные пакеты — например godep (запоминает commit sha, создает своего рода аналог virtualenv, но для Go приложений). Есть и множество других пакетных менеджеров, но в целом вопрос версий остается открытым.
P.S. Язык Go мне нравится, просто поделился мыслями после прочтения статьи. Автору спасибо!
Мартини довольно еще молодой (в сравнении с Гориллой), но развивающийся огромными темпами. Простой и доступный, как мне показалось.
*просто мои 5 копеек к вашим мыслям*
*просто мои 5 копеек к вашим мыслям*
Тоже так думаю. Даже пример проекта с оф. сайта martini в видео впечатляет. Думаю по размерам сообщества — martini сейчас самый популярный среди Go frameworks.
Радует и martini-contrib с дополнительными плюшками вроде oauth, распознавания языков, gzip и т.п. Хотя gzip и обработку ssl я бы оставил все-таки на nginx. В Go 1.3 планируются изменения в tls пакете — найдены уязвимости и они решили изменить там немного API.
Радует и martini-contrib с дополнительными плюшками вроде oauth, распознавания языков, gzip и т.п. Хотя gzip и обработку ssl я бы оставил все-таки на nginx. В Go 1.3 планируются изменения в tls пакете — найдены уязвимости и они решили изменить там немного API.
Спасибо за ваши мысли. Как мне кажется основная проблема Martini — это производительность из-за DI, но всё это решается небольшими правками и кэшированием, благо код очень компактный. Зато на другой стороне — упрощение и ускорение разработки, что, как мне кажется, намного важнее.
Martini крут своей простотой! Отличный фреймворк, позволяющий быстро начать работу. Да, с DI есть некоторое падение производительности. И чем больше «замаплено» в контекст, тем больше деградация. Но плюс в том, что при желании можно отказаться от использования martini в любой момент. Так как он «Fully compatible with the http.HandlerFunc interface», при соответствующей нотации.
UFO just landed and posted this here
Нужно смотреть исходники, но думаю в DI вся красота Martini и есть. Как тут написали — код становится компактнее, добавлять переменные в часть handlers проще, добавлять middlewares проще.
Но если без DI обходиться, но можно делать примерно так:
и потом при регистрации handlers писать примерно так:
Ну и пример MyHandler:
Тоесть определяется CustomHandler struct и поскольку ее Handler реализует метод ServeHTTP он может быть использован как Handler стандартным http пакетом из библиотеки Go.
Но если без DI обходиться, но можно делать примерно так:
type CustomHandler struct {
Mongo *mgo.Session
Handler func(http.ResponseWriter, *http.Request, *mgo.Database, *sessions.Session)
}
func (ha *CustomHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
db := ha.Mongo.Clone().DB("")
ha.Handler(w, r, db)
}
и потом при регистрации handlers писать примерно так:
http.Handle("/my/url/", &CustomHandler{mongo, MyHandler})
Ну и пример MyHandler:
func MyHandler(w http.ResponseWriter, r *http.Request, db *mgo.Database) {
// implementation goes here...
}
Тоесть определяется CustomHandler struct и поскольку ее Handler реализует метод ServeHTTP он может быть использован как Handler стандартным http пакетом из библиотеки Go.
Забавно. Примерно для таких же целей написал для себя HTTP Echo сервис — это 100 строк на Python, собственный примитивный парсер HTTP. Но он не логгирует куда-то, а просто возвращает запрос как есть в теле ответа (ну, плюс в первой строчке IP и порт запросившего).
Главный минус — написан в блокирующем стиле и однопоточный. Но для личных нужд более чем достаточно.
Главный минус — написан в блокирующем стиле и однопоточный. Но для личных нужд более чем достаточно.
Sign up to leave a comment.
Пишем веб сервис на Go (часть первая)