[Перевод] Создание веб-приложения на Go в 2017 году
Комментарии (10)
comerc
27 мая 2017 в 11:48
0↑
↓
Прекрасная статья для начинающих и подоспела вовремя. Последние выходные мая — лучше не придумаешь, чтобы написать свое первое приложение на Go.
Merlen_Gross
27 мая 2017 в 12:23
0↑
↓
Tornado решает проблему C10K. Автор слишком быстро отбросил Python.
27 мая 2017 в 17:58
0↑
↓
Автор, похоже, не догадывается, что проблема C10K уже не актуальна, и все решают проблему C10M:) Да и тот же uvloop в python вполне может тягаться с go, а местами даже и выигрывать.
kilgur
27 мая 2017 в 18:28
0↑
↓
Если внимательно почитать статью по вашей ссылке, то там есть такой текст:We use Python 3.5, and all servers are single-threaded. Additionally, we use GOMAXPROCS=1 for Go code, nodejs does not use cluster, and all Python servers are single-process.
У Go нет GIL. Когда вы захотите «заюзать» сервер целиком со всеми его ядрами, начнется «балансировщик запросов, разделяемый кэш, …» и далее по тексту. В Go вам просто не надо будет выставлять GOMAXPROCS=1 и оно «как-то само» по всем ядрам «расползется»…
Я, разумеется, утрирую…, но доля истины в моем комментарии есть.
27 мая 2017 в 12:44
0↑
↓
фреймворк является необязательным и не рекомендуется.
Да, на Golang нет особой необходимости в сложных фреймворках.
Но мне нужна была функциональность middleware для сервиса — я выбрал https://github.com/labstack/echo. Да, можно сделать самому, но зачем?…
Не знаю, насколько верное решение, время покажет.Спасибо за статью.
27 мая 2017 в 14:33
–1↑
↓
Может быть есть и другие подобные языки, но с моей точки зрения, в мире доминируют Python и Ruby.
Не хочу вас расстраивать, но в мире веб-дева доминирует php)
bano-notit
27 мая 2017 в 15:06 (комментарий был изменён)
0↑
↓
Интересно это конечно всё, но отсутствие фреймворков — проблема, причём реальная. SPA — очень спорная часть жизни веба, с одной стороны это конечно хорошо и тихий переход к вебу как к платформе, но именно это же и убивает лёгкость веба. Тогда уж легче и экономнее будет установить нативное приложение, чем хранить в кеше 1000 строк js кода. Так что в этом моменте я бы поспорил, хотя сам очень люблю SPA.
А вот фреймворки реально нужны, в любом случае. И не потому, что яп не спроектирован под веб, а потому, что хочется иметь модульность проекта, лёгкость работы с ним и низкий порог входа в проект. Фреймворки в каком-то смысле создают стандартны написания и комьюнити, а оно в свою очередь профессионалов, с которыми легко работать именно в контексте этого фреймворка. Ведь в какой-то момент команда может поменяться полностью, и мало кто захочет копаться в нативном громоздком коде, написанным какими-то людьми несколько лет назад по каким-то своим правилам.
vansickle
27 мая 2017 в 16:37
0↑
↓
Для начала, Go не поддерживает объекты — то, что обозначено O в аббревиатуре ORM.
Что вы имели в виду под «Go не поддерживает объекты»?
-
kilgur
27 мая 2017 в 17:05
0↑
↓
Цитата из википедии: «Наличие инкапсуляции достаточно для объектности языка программирования, но ещё не означает его объектной ориентированности — для этого требуется наличие наследования.» Инкапсуляция в Go есть, да, а вот наследования нет. На мой взгляд тут автор слегка «переборщил» — наследование не самая важная часть ORM.27 мая 2017 в 18:02
0↑
↓
Наследование таблиц/моделей очень помогает при реализации связей One-to-one, например. У нас в проекте есть 3 вида пользователей, каждый из которых использует свой механизм авторизации (требование законов). Так вот базовая часть каждого типа хранится в одной таблице.
