Go: Встроенный backend vs app engine

Question

Я один из тех классических программистов, которые потратили большую часть своего прошлого на файлы .exe и .jar. С прошлого года я бросил себя в мир веб-фреймворков и технологий, которые захватывают меня, чтобы произвести на меня впечатление. По состоянию на прошлые 1½ месяца я влюбился в Go из-за его строгости, а также как «автономный», как кажется. Итак, теперь к реальному вопросу ...

• Перейти к приложению приложения для приложений, зачем нам это нужно?

• В чем разница и аргументы в выборе обернутого приложения (рамки)?

Я предполагаю, что его цель состоит в том, чтобы загрузить некоторые связи выключения приложения к обертке, но, к сожалению, я не могу показаться, чтобы выяснить (через документацию и обсуждения), что конкретная цель позади этой модуляции.

С уважением, и кибер высокой пятерки в вашем направлении!

Answer 1

Это действительно два разных вопроса.

1. Почему GAE?

Это зависит от вас. GAE предоставляет облачный хостинг, который вы платите за аренду. Это немного похоже на Amazon Web Services. Ваше приложение Go будет загружено в GAE, где оно предоставит ваш веб-сервис, и ваши пользователи смогут делать много замечательных вещей. Между тем вам никогда не нужно знать, какой фактический сервер выполняет обслуживание в любой момент времени - приложение может динамически перемещаться по своим серверам. GAE обеспечивает высокое время безотказной работы и низкие усилия для обеспечения безопасности сервера, резервного копирования и т. Д. Он также будет эластичным, чтобы справляться с перенапряжениями в нагрузке.

Возможно, вы предпочитаете арендовать частный сервер (например, в Rackspace) или просто виртуальную машину. Вы, вероятно, должны быть экспертом по Linux (получите большую помощь в Serverfault), и вам придется делать резервную копию, брандмауэр и т. Д. Все самостоятельно. Это может стоить (много) нет. Или больше.

2. Выбор рамы?

API net/http позволяет писать код HTTP-сервера, чтобы делать все, что угодно. Но вам нужно много тяжело работать. В противоположной крайности, такие рамки, как Revel, делают возможным быстрое развитие сервера, если оно делает то, что вы хотите от него. Если вы блуждаете по функциональности, помимо того, что она предлагает, вам, возможно, придется довольно много выкапывать, чтобы узнать, как расширить рамки.

Другие интересные инструменты включают Gorilla, Gocraft Web и Goji. С точки зрения сложности они сидят примерно на полпути между Ревелем и базовой сетью/http.

Answer 2

Чтобы ответить на ваш второй вопрос, вот некоторые плюсы и минусы использования фреймворка (например, revel) по сравнению с чем-то более простым, как набор инструментов (например,, Горилла)

В общем, плюсы использования рамки являются:

• обеспечивает много суб-пакетов для обработки важных веб-связанных подзадач, как шаблонам, генерируют данные в указанный форматы, такие как JSON или XML, запрос отводящего и т.д.
• он обрабатывает шаблонные обработки HTTP
• это (надеюсь) применяет лучшие практики, как вылетающие строки
• это помогает вам управлять сложностью путем применения в состо ли нт дизайн шаблон, как вы обрабатывать запросы

Минусы использования рамки:

• рамка имеет тенденцию быть «упрямыми» означает, что вы должны купить в их общую философию и понять их ядро концепции, прежде чем вы сможете их использовать; для многих фреймворков это может быть довольно немного умственного наводнения.
• дополнительный слой абстракции, означающий, что вы еще один шаг удалили от того, что действительно происходит, и будет больше вещей, чтобы понять и отладить, если что-то пойдет не так
• он может быть хрупким и трудно сделать что-то, что не является стандартным вариантом использования в каркасе
• будущая ремонтопригодность: большинство каркасов не имеют сверхдлительного срока службы. Django и Rails давно существуют, но есть огромное кладбище фреймворков, которые были перед ними. Оглядываясь назад, 20/20, но с самого начала трудно выбрать правильную лошадь.

Рекомендация

Это трудно сделать вызов заранее. Так много зависит от специфики вашей проблемы, но я бы сказал, в случае Go, выберите более простой вариант. Большая часть добавленной стоимости фреймворков на других языках заключается в том, что они содержат полезные подпакеты, которые обрабатывают важные задачи, но Go уже содержит много из них в своей стандартной библиотеке (например, encoding/json, net/http, net/url, text/template). Я построил fairly sophisticated web app, используя только набор инструментов Gorilla и стандартную библиотеку, и это было потрясающе хорошо, и лучшая часть - это невероятно просто понять, что делает код, и я могу объяснить это кому-то другому, не требуя от них сначала прочитайте массивную страницу о какой-либо сторонней структуре.

Если вы хотите понять, как другие люди используют Gorilla, вы можете попробовать посмотреть на real-world usage examples. Сравните это с тем, как люди используют более сложные рамки и выбирают то, что вам больше нравится.