Комментарии 5
Меня одного забавляет тот факт, что в статье про Go прорекламированы все возможные курсы, кроме самого Go?
Было бы здорово показать, как получать параметры из пути и/или формы, желательно с валидацией.
Также хотя бы пару слов про fasthttp — раз в 10 быстрее, но с проблемами совместимости со стандартным net/http.
Также хотя бы пару слов про fasthttp — раз в 10 быстрее, но с проблемами совместимости со стандартным net/http.
Было бы здорово показать, как получать параметры из пути и/или формы, желательно с валидацией.
Но ведь на примере go-chi/chi показано, как получить параметр из пути...
func NewRouter() http.Handler {
router := chi.NewRouter()
r.Get("/{name}", HelloName)
return r
}
func HelloName(w http.ResponseWriter, r *http.Request) {
name := chi.URLParam(r, "name")
response := HelloResponse{
Message: fmt.Sprintf("Hello %s!", name),
}
}Получение параметров из формы — это уже парсинг body/query запроса, там сложностей нет.
Валидация параметров роута — в документации к роутеру (например, тот же chi):
// Regexp url parameters:
r.Get("/{articleSlug:[a-z-]+}", getArticleBySlug)Да, Вы абсолютно правы, спасибо!
многого всякого сделал на Go, и микросервисы, и файловые бд для простых нетривиальных задач, и много чего другого…
но Go — не такой прост как кажеться, и то что описано в переводе — вредно и опасно, далеко от реальности…
А в делах повседневных сталкиваться приходиться и с бд, и с конкурентностью и с гонкой данных, которые не всегда возможно избежать (особенно новичкам), и тур в го и лучшие практики на офф.сайте не всегда дают исчерпывающий ответ на вопросы как поступить в конкретном общепринятом случае… в результате получается странное переиспользование памяти, тормозящий сборщик мусора и тупо переполнение тсп стека или к-во соединений целевой бд… (зароется один червь в большом проекте — поседеете пока отладите)
но я не об этом… низкий порог вхождения, много готовых либ, удобный синтаксис и т.п…
сегодня столкнулся с простой задачей, есть 5 функций, каждая использует переменную Х, этот Х делается глобальным в пределах сорса (выше func main объявляется как var x []byte — например), потому что — зачем сшивать этой переменной все функции.
далее — внимание, делается чтото типо:
и тут самый интересный конфюз… много всяких неоднозначностей и странностей описывал в остальных комментах к постам о якобы простом Go.
…
вот на прошлой недели была очень тупая и простая задача, есть 170+ баз данных в mcaccess, есть утилита которая делает из мс аксес экспорт в таблиц и данных для конкретной бд (по другому она не умеет, даже пароль не просит, крутая утилита)… я столкнулся с проблемой использования возможностей из коробки, ибо мой многопоточный скрипт генерил примерно 6гб данных примерно за 40 минут (базы и связки привда сложные и их было много, кроме того тулза для каждой бд могда экспортировать только 1 таблицу, тоесть если бд в 100мб и 10 таблиц, то 100мб проганяется 10 раз)…
психонул, ибо это не дело… написал тупой алгоритм на си, вместо 40сек получил 19сек, я не хотел разбираться почему в любимом Go что-то не работало быстро, искать узкие места и т.п., но вернулся к старому и доброму: лучше потрахаться на уровне компиляции «вычленяя» проблемы указателей, чем потом отлаживать проект в несколько тысяч строк в поисках логической ошибки… и профайлер не панацея.
это кстати больше всего бесит (на начальных парах) — можно заставить работать мапинг «неправильно», случайно, а потом он будет крашиться, но все скомпилируется…
но Go — не такой прост как кажеться, и то что описано в переводе — вредно и опасно, далеко от реальности…
А в делах повседневных сталкиваться приходиться и с бд, и с конкурентностью и с гонкой данных, которые не всегда возможно избежать (особенно новичкам), и тур в го и лучшие практики на офф.сайте не всегда дают исчерпывающий ответ на вопросы как поступить в конкретном общепринятом случае… в результате получается странное переиспользование памяти, тормозящий сборщик мусора и тупо переполнение тсп стека или к-во соединений целевой бд… (зароется один червь в большом проекте — поседеете пока отладите)
но я не об этом… низкий порог вхождения, много готовых либ, удобный синтаксис и т.п…
сегодня столкнулся с простой задачей, есть 5 функций, каждая использует переменную Х, этот Х делается глобальным в пределах сорса (выше func main объявляется как var x []byte — например), потому что — зачем сшивать этой переменной все функции.
далее — внимание, делается чтото типо:
func fZ(){
....
x, err := ioutil.ReadAll(z);
...
}и тут самый интересный конфюз… много всяких неоднозначностей и странностей описывал в остальных комментах к постам о якобы простом Go.
…
вот на прошлой недели была очень тупая и простая задача, есть 170+ баз данных в mcaccess, есть утилита которая делает из мс аксес экспорт в таблиц и данных для конкретной бд (по другому она не умеет, даже пароль не просит, крутая утилита)… я столкнулся с проблемой использования возможностей из коробки, ибо мой многопоточный скрипт генерил примерно 6гб данных примерно за 40 минут (базы и связки привда сложные и их было много, кроме того тулза для каждой бд могда экспортировать только 1 таблицу, тоесть если бд в 100мб и 10 таблиц, то 100мб проганяется 10 раз)…
психонул, ибо это не дело… написал тупой алгоритм на си, вместо 40сек получил 19сек, я не хотел разбираться почему в любимом Go что-то не работало быстро, искать узкие места и т.п., но вернулся к старому и доброму: лучше потрахаться на уровне компиляции «вычленяя» проблемы указателей, чем потом отлаживать проект в несколько тысяч строк в поисках логической ошибки… и профайлер не панацея.
это кстати больше всего бесит (на начальных парах) — можно заставить работать мапинг «неправильно», случайно, а потом он будет крашиться, но все скомпилируется…
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Разработка веб-серверов на Golang — от простого к сложному