Вы можете попробовать что-то вроде следующего, чтобы найти столбец, содержащий символ не-ascii:
select * from your_table where your_col <> asciistr(your_col);
На Безграничный мы углубились в вариант # 2 и представили его тысячам студентов. Наш сервер представляет собой JSON REST API (Scala + MongoDB), и весь наш клиентский код обслуживается прямо из CloudFront (то есть: www.boundless.com - это просто псевдоним CloudFront).
Плюсы:
Минусы:
Я действительно думаю, что это будущее всех веб-приложений.
Некоторые мысли для пользователей веб-интерфейса (вот где вся новизна / вызов дается этой архитектуре):
Мы создали жгут для нашей интерфейсной разработки под названием «Spar» (одностраничное приложение Rocketship), которое фактически представляет собой конвейер ресурсов от Rails, настроенный для разработки одностраничных приложений. В течение следующих нескольких недель мы будем открывать ресурсы на нашей странице github вместе с сообщением в блоге, объясняющим, как использовать его и общую архитектуру более подробно.
ОБНОВЛЕНИЕ:
Что касается проблем людей с Backbone, я думаю, что они переоценены. Магистраль - это скорее организационный принцип, чем глубокая структура. Сам сайт Твиттера - гигантский зверь из Javascript, охватывающий каждый кейс для миллионов пользователей. устаревшие браузеры, загружая твиты в реальном времени, собирая мусор, отображая большое количество мультимедиа и т. д. Из всех «чистых» js-сайтов, которые я видел, Twitter - самый странный. Было много впечатляюще сложных приложений, доставленных через JS, которые очень хорошо работают.
И ваш выбор архитектуры полностью зависит от ваших целей. Если вы ищете самый быстрый способ поддержки нескольких клиентов и имеете доступ к хорошим фронтенд-талантам, инвестирование в автономный API - отличный способ.
Создание JSON API в Rails - это первый класс, гем JSONAPI :: Resources делает тяжелую работу для http://jsonapi.org специального API.
Я решил перейти к архитектуре варианта № 2 для Infiniforms , поскольку он предоставил отличный способ отделить пользовательский интерфейс от бизнес-логики.
Преимущество этого заключается в том, что серверы API могут масштабироваться независимо от веб-серверов. Если у вас несколько клиентов, веб-сайтам не нужно масштабироваться в той же степени, что и веб-серверы, поскольку некоторые клиенты будут работать на телефоне / планшете или на настольном компьютере.
Этот подход также дает вам хорошую базу для открытия вашего API для ваших пользователей, особенно если вы используете свой собственный API, чтобы обеспечить все функциональные возможности для вашего веб-сайта.
Я лично предпочитаю вариант (3) в качестве решения. Он используется почти на всех сайтах моего бывшего (фамилии) работодателя. Это означает, что вы можете получить некоторых разработчиков интерфейса, которые знают все о Javascript, особенностях браузера и еще много чего, чтобы закодировать ваш интерфейс. Им нужно знать только «curl xyz, и вы получите немного json», и они уходят.
Тем временем ваши тяжелые бэкэнды могут кодировать поставщиков Json. Этим ребятам вообще не нужно думать о представлении, а вместо этого беспокоятся о нестабильных бэкэндах, тайм-аутах, изящной обработке ошибок, пулах соединений с базами данных, потоке, масштабировании и т. Д.
Вариант 3 дает хорошую, прочную трехуровневую архитектуру. Это означает, что материал, который вы выплевываете из внешнего интерфейса, оптимизирован для SEO, может быть приспособлен для работы со старыми или новыми браузерами (и с отключенным JS), и все же может быть Javascript на стороне клиента, если хотите (можно делайте что-то вроде обработки старых браузеров / googlebot со статическим HTML, но отправляйте JS встроенные динамические приложения людям, использующим последний браузер Chrome или любой другой).
Во всех случаях, которые я видел в Варианте 3, это была пользовательская реализация некоторого PHP, который не особенно переносим между проектами, не говоря уже о том, чтобы выходить на землю с открытым исходным кодом. Я предполагаю, что совсем недавно PHP, возможно, заменили на Ruby / Rails, но то же самое по-прежнему верно.
FWIW, $ current_employer мог бы сделать с вариантом 3 в нескольких важных местах. Я ищу хороший Ruby-фреймворк для сборки чего-либо. Я уверен, что смогу собрать воедино множество драгоценных камней, но я бы предпочел один продукт, который в целом предоставляет шаблонное, «скручиваемое», дополнительное аутентификация, дополнительное решение для кэширования с использованием memcache / nosql. Там я не могу найти ничего связного: - (
Очень хороший вопрос, и я удивлен, поскольку думал, что это очень распространенная задача в настоящее время, так что у меня будет достаточно ресурсов для этой проблемы, однако оказалось, что это не так.
Мои мысли заключаются в следующем: - Создать какой-то модуль, который имеет общую логику между контроллерами API и контроллерами HTML без возврата json или рендеринга html, и включить этот модуль как в контроллер HTML, так и в контроллер API, затем делайте что хотите, например:
module WebAndAPICommon
module Products
def index
@products = # do some logic here that will set @products variable
end
end
end
class ProductsController < ApplicationController
# default products controlelr, for rendering HMTL pages
include WebAndAPICommon
def index
super
end
end
module API
class ProductsController
include WebAndAPICommon
def index
super
render json: @products
end
end
end
Для atyourservice.com.cy мы используем серверные отрендеренные шаблоны для страниц, особенно для покрытия самой части. И использование API для взаимодействия после загрузки страницы. Поскольку наша структура MVC, все функции контроллера дублируются на вывод json и вывод html. Шаблоны чистые и получают только объект. Это может быть преобразовано в JS шаблоны в считанные секунды. Мы всегда поддерживаем шаблоны на стороне сервера и просто возвращаемся к js по запросу.
Я выбрал гибридный подход, в котором мы используем Sinatra в качестве основы, ActiveRecord / Postgress и т. Д. Для обслуживания маршрутов страниц (тонкие шаблоны), чтобы предоставить REST API, который веб-приложение может использовать. На ранних этапах разработки такие вещи, как заполнение опций выбора, выполняются посредством рендеринга помощников в тонкий шаблон, но по мере приближения к производству это заменяется вызовом AJAX REST API, поскольку мы начинаем больше заботиться о скорости загрузки страниц и так далее.
Вещи, которые легко визуализировать в Slim, обрабатываются таким образом, а вещи (заполнение форм, получение данных POST формы из jQuery. Validation submitHandler
и т. Д., Все явно AJAX)
Тестирование - это проблема , Сейчас я в тупике , пытаясь передать данные JSON в тест Rack :: Test POST .
Мы выбрали № 2 при создании колеи. Я работал над API (ruby, sinatra и т. Д.), А мой деловой партнер, Стив Смит, работал над интерфейсом (клиент javascript).
Плюсы:
Быстро двигаться параллельно. Если бы я работал раньше Стива, я мог бы продолжать создавать API для новых функций. Если бы он работал впереди меня, он мог бы очень легко подделать API и создать пользовательский интерфейс.
API бесплатно. Наличие открытого доступа к данным в вашем приложении быстро становится стандартной функцией. Если вы начнете с API с нуля, вы получите это бесплатно.
Чистое разделение. Лучше думать о вашем приложении как о API для клиентов. Конечно, первым и самым важным клиентом может быть веб-клиент, но он настраивает вас на простоту создания других клиентов (iPhone, Android).
Минусы:
Я не могу больше думать о минусах прямо сейчас.
Вывод: клиент API + JS - это то, что нужно, если вы планируете выпустить API.
P.S. Я также рекомендовал бы полностью документировать ваш API перед его выпуском. Процесс документирования API Gaug.es действительно помог нам чертить
Здесь уже есть несколько хороших ответов - я определенно рекомендую № 2 или № 3 - разделение хорошо как в концептуальном плане, так и на практике.
Может быть трудно предсказать такие вещи, как загрузка и шаблоны трафика для API, и клиенты, которых мы видим, кто обслуживает API независимо, имеют более легкое время предоставления и масштабирования. Если вам нужно сделать это в сочетании с шаблонами доступа в Интернет, это будет не так просто. Кроме того, использование вашего API может в конечном итоге расширяться намного быстрее, чем ваш веб-клиент, и тогда вы сможете увидеть, куда направить свои усилия.
Между № 2 и 3 это действительно зависит от ваших целей - я согласен, что № 2, вероятно, будущее веб-приложений - но, возможно, вы хотите что-то более прямолинейное, если этот канал станет одним из многих!
Я предпочитаю идти по маршруту № 2 и № 3. Главным образом потому, что № 1 нарушает разделение проблем и смешивает все виды вещей. В конце концов вы обнаружите необходимость иметь конечную точку API, которая не имеет соответствующей HTML-страницы / и т. Д., И вы получите ручей с смешанными конечными точками HTML и JSON в одной и той же базе кода. Это превращается в ужасный беспорядок, даже если его MVP, вам придется переписать его в конце концов, потому что он настолько грязный, что его даже не стоит спасать.
Использование # 2 или # 3 позволяет вам полностью иметь API, который действует одинаково (по большей части) независимо. Это обеспечивает большую гибкость. Я еще не продан на 100% на Backbone / ember / whats / etc.js. Я думаю, это здорово, но, как мы видим в твиттере, это не оптимально. НО ... Твиттер также является огромным зверем компании и имеет сотни миллионов пользователей. Таким образом, любое улучшение может иметь огромное влияние на практический результат в различных областях различных бизнес-единиц. Я думаю, что в этом есть нечто большее, чем просто скорость, и нас это не пускает. Но это только мое мнение. Однако я не сбрасываю со счетов магистраль и его конкурентов. Эти приложения удобны в использовании, очень чисты и очень отзывчивы (по большей части).
Третий вариант также имеет определенную привлекательность. Здесь я следую принципу Парето (правило 80/20) и получаю 20% вашей основной разметки (или наоборот) на сервере, а затем выполняю хороший клиент JS (магистраль / и т. Д.) Для запуска остальной части. , Возможно, вы не на 100% обмениваетесь данными с API REST через JS-клиент, но при необходимости вы будете выполнять некоторую работу, чтобы улучшить работу с suer.
Я думаю, что это одна из тех «это зависит» от вида проблем, и ответ «это зависит» от того, что вы делаете, кому вы служите и какой опыт вы хотите, чтобы они получили , Учитывая, что я думаю, вы можете выбрать между 2 или 3 или гибрид из них.
Мне нравится №3, когда мой сайт не будет 100% CRUD-реализацией моих данных. Что еще должно произойти.
Я предпочитаю sinatra и просто разделю приложение на несколько разных стоечных приложений с разными целями. Я сделаю специальное приложение для стойки, которое охватит все, что мне нужно для API. Тогда, возможно, приложение пользовательской стойки, которое представит мою веб-страницу. Иногда эта версия будет запрашивать API при необходимости, но обычно это касается только html-сайта.
Я не беспокоюсь об этом и просто делаю запрос уровня персистентности со стороны пользователя, если мне это нужно. Я не слишком озабочен созданием полного разделения, поскольку они обычно служат различным целям.
Вот очень простой пример использования нескольких стоечных приложений. Я добавил быстрый пример jquery, чтобы вы увидели, что он работает с приложением API. Вы можете увидеть, насколько просто это может быть с sinatra и монтированием нескольких стоечных приложений для разных целей.
У меня около 2 месяцев в 3-месячном проекте, который использует второй подход, который вы изложили здесь. Мы используем серверную часть RESTful API с backbone.js на передней панели. Handlebars.js управляет шаблонами, а jQuery обрабатывает манипуляции с AJAX и DOM. Для более старых браузеров и поисковых пауков мы остановились на рендеринге на стороне сервера, но мы используем те же шаблоны HTML, что и интерфейс Handlebars, используя Mozilla Rhino.
Мы выбрали этот подход по многим различным причинам, но очень хорошо знаем, что это немного рискованно, учитывая, что это еще не было доказано в широком масштабе. Все то же самое, пока все идет довольно гладко.
Пока что мы только что работали с одним API, но на следующем этапе проекта мы будем работать со вторым API. Первый предназначен для больших объемов данных, а второй действует больше как CMS через API.
Наличие этих двух частей проекта, полностью независимых друг от друга, было ключевым фактором при выборе этой инфраструктуры. Если вы ищете архитектуру для смешивания различных независимых ресурсов без каких-либо зависимостей, то этот подход стоит посмотреть.
Боюсь, я не Ruby, поэтому не могу комментировать другие подходы. Иногда можно рисковать. В других случаях лучше не рисковать. Вы будете в зависимости от типа проекта.
Желаем удачи с вашим выбором здесь. Желая увидеть, что разделяют и другие.
Обычно я выбираю второй вариант, использующий Rails для создания API, и основу для JS. Вы даже можете получить панель администратора бесплатно, используя ActiveAdmin . Я поставил десятки мобильных приложений с таким бэкэндом. Однако это сильно зависит от того, является ли ваше приложение интерактивным или нет.
Я сделал презентацию об этом подходе на последнем RubyDay.it : http://www.slideshare.net/matteocollina/enter-the-app-era-with -ruby-on-rails-rubyday
Для третьего варианта, чтобы получить отзывчивость второго, вы можете попробовать pajax , как это делает Github.
В настоящее время я работаю над преобразованием огромной CMS из варианта 1 в вариант 3, и все идет хорошо. Мы выбрали визуализацию на стороне сервера, потому что SEO очень важен для нас, и мы хотим, чтобы сайты работали на мобильных телефонах.
Я использую node.js для серверной части клиента и несколько модулей, чтобы помочь мне. Я немного рано в этом процессе, но основа заложена, и это вопрос просмотра данных, чтобы все было правильно. Вот что я использую:
Это ядро стека. Некоторые другие модули, которые я нашел полезными:
Нет, я не использую coffeescript.
Этот вариант работает очень хорошо для меня. Модели на внутреннем сервере не существуют, потому что данные, которые мы получаем от API, хорошо структурированы, и я передаю их дословно внешнему интерфейсу. Единственное исключение - наша модель макета, где я добавляю один атрибут, который делает рендеринг умнее и легче. Я не использовал для этого никакой библиотеки модных моделей, просто функцию, которая добавляет то, что мне нужно при инициализации, и возвращает себя.
(извините за странные ссылки, я слишком много n00b для переполнения стека, чтобы позволить мне публиковать так много)
REST-сервер + тяжелый JavaScript-клиент был принципом, которому я следовал в своей недавней работе.
REST-сервер был реализован в node.js + Express + MongoDB (очень хорошая производительность записи) + Mongoose ODM (отлично для моделирования данных, включая проверки) + CoffeeScript (я бы сейчас использовал ES2015 вместо этого), который хорошо сработал для меня. Node.js может быть относительно молодым по сравнению с другими возможными серверными технологиями, но это позволило мне написать надежный API с интегрированными платежами.
Я использовал Ember.js в качестве среды JavaScript, и большая часть логики приложения была выполнена в браузере. Я использовал SASS (в частности, SCSS) для предварительной обработки CSS.
Ember - зрелая структура, поддерживаемая сильным сообществом. Это очень мощный фреймворк, в котором в последнее время проводится много работы, ориентированной на производительность, например, новый движок рендеринга Glimmer (по мотивам React).
Ember Core Team находится в процессе разработки FastBoot , который позволит вам выполнить вашу логику Ember JavaScript на стороне сервера (в частности, node.js) и отправлять предварительно отрендеренный HTML-код вашего приложения (что будет обычно запускается в браузере) пользователю. Это здорово для SEO и пользовательского опыта, так как он не ждет так долго, пока страница не появится.
Ember CLI - это отличный инструмент, который помогает вам организовать ваш код, и он хорошо масштабировался с ростом кодовой базы. Ember также имеет свою собственную аддонную экосистему, и вы можете выбирать из множества Ember Addons . Вы можете легко взять Bootstrap (в моем случае) или Foundation и добавить его в свое приложение.
Чтобы не обслуживать все через Express, я решил использовать nginx для обслуживания изображений и клиент с большим количеством JavaScript. Использование прокси-сервера nginx было полезно в моем случае:
upstream app_appName.com {
# replace 0.0.0.0 with your IP address and 1000 with your port of node HTTP server
server 0.0.0.0:1000;
keepalive 8;
}
server {
listen 80 default_server;
listen [::]:80 default_server ipv6only=on;
client_max_body_size 32M;
access_log /var/log/nginx/appName.access.log;
error_log /var/log/nginx/appName.error.log;
server_name appName.com appName;
location / {
# frontend assets path
root /var/www/html;
index index.html;
# to handle Ember routing
try_files $uri $uri/ /index.html?/$request_uri;
}
location /i/ {
alias /var/i/img/;
}
location /api/v1/ {
proxy_pass http://app_appName.com;
proxy_next_upstream error timeout invalid_header http_500 http_502
http_503 http_504;
proxy_redirect off;
proxy_buffering off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
Pro: Мне нравится разделение API & amp; клиент. Умные люди говорят, что это путь. Великолепно в теории. Кажется передовым и захватывающим.
Я могу сказать, что это также здорово на практике. Еще одним преимуществом разделения REST API является то, что вы можете использовать его позже для других приложений. В идеальном мире вы должны иметь возможность использовать один и тот же API REST не только для веб-страниц, но и для мобильных приложений, если решите написать его.
Против: не так много прецедентов. Не много примеров этого сделано хорошо. Публичные примеры (twitter.com) чувствуют себя вялыми даже отказываются от этого подхода.
Теперь все выглядит иначе. Есть много примеров использования REST API + много клиентов, использующих его.
Мы используем следующий вариант # 3: Создаем только JSON-сервер REST API. Сделать сервер веб-сайта HTML. Веб-сервер HTML, как и в вашем варианте, не является клиентом сервера API REST. Вместо этого оба сверстники. Недалеко от поверхности находится внутренний API, который обеспечивает функциональность, необходимую двум серверам.
Мы не знаем ни о каком прецеденте, так что это своего рода эксперимент. Пока (собирается войти в бета-версию), это сработало довольно хорошо.
Изоморфный рендеринг и прогрессивное улучшение. К чему, я думаю, вы клонировали в третьем варианте.
изоморфный рендеринг означает использование того же шаблона для генерации разметки на стороне сервера, который используется в коде на стороне клиента. Выберите шаблонный язык с хорошими реализациями на стороне сервера и на стороне клиента. Создайте полностью запеченный HTML для своих пользователей и отправьте его по проводам. Используйте кеширование тоже.
прогрессивное улучшение означает, что вы начнете выполнять на стороне клиента выполнение, рендеринг и прослушивание событий, как только вы загрузите все ресурсы и сможете определить возможности клиента. Возвращаясь к функциональности без клиентских скриптов, везде, где это возможно, для доступности и обратной совместимости.
Да, конечно, напишите автономный JSON API для функциональности этого приложения. Но не заходите так далеко, что вы пишете JSON API для вещей, которые отлично работают как статические HTML-документы.
Я использовал первые два варианта. Первый для многочисленных приложений и второй для моего проекта с открытым исходным кодом Cowoop
Вариант 1
Этот, без сомнения, самый популярный. Но я считаю, что реализация очень много http-иш. Каждый исходный код API относится к объекту запроса. Таким образом, код API - это больше, чем просто код ruby / python / другого языка.
Вариант 2
Я всегда любил это.
Эта опция также подразумевает, что HTML не генерируется во время выполнения на сервере. Это отличает вариант 2 от варианта 3. Но он создается как статический html с использованием сценария сборки. При загрузке на стороне клиента эти HTML будут вызывать сервер API как клиент JS API.
Разделение интересов является большим преимуществом. И очень по вашему вкусу (и моему) бэкэнд-эксперты внедряют бэкэнд-API, тестируют их легко, как обычный языковой код, не беспокоясь о коде запроса framework / http.
Это действительно не так сложно, как звучит на внешней стороне. Вызовы API и полученные данные (в основном, json) доступны для вашего клиентского шаблона или MVC.
Меньше обработки на стороне сервера. Это означает, что вы можете перейти на обычное оборудование / менее дорогой сервер.
Легче тестировать слои независимо, проще создавать документы API.
У него есть некоторые недостатки.
Многим разработчикам это сложно и сложно понять. Таким образом, есть вероятность, что архитектура может подвергнуться критике.
i18n / l10n сложно. Поскольку HTML по сути генерируется, время сборки статично, для каждого поддерживаемого языка требуется несколько сборок (что не обязательно плохо). Но даже при этом вы можете иметь угловые случаи около l10n / i18n и вам нужно быть осторожным.
Вариант 3
В этом случае внутреннее кодирование должно совпадать со вторым вариантом. Большинство пунктов для варианта 2 применимы и здесь.
Веб-страницы отображаются во время выполнения с использованием шаблонов на стороне сервера. Это значительно облегчает работу с более устоявшимися / принятыми методами. Может быть на один HTTP-вызов меньше для некоторого существенного контекста, необходимого для рендеринга страницы, такого как пользователь, язык, валюта и т. Д. Таким образом, обработка на стороне сервера увеличивается при рендеринге, но, возможно, компенсируется меньшим количеством http-вызовов к API-серверу.
Теперь, когда страницы отображаются на сервере, интерфейс теперь больше связан с программной средой. Это может даже не учитываться для многих приложений.
Как я понимаю, Twitter может выполнять свою первоначальную визуализацию страниц на сервере, но для обновления страниц он все еще имеет некоторые вызовы API и шаблоны на стороне клиента для манипулирования DOM. Таким образом, в таком случае у вас есть двойные шаблоны для обслуживания, что добавляет некоторые накладные расходы и сложность. Не каждый может позволить себе этот вариант, в отличие от Twitter.
Я использую Python. Я использую JsonRPC 2.0 вместо REST. Я предлагаю REST, хотя мне нравится идея JsonRPC по разным причинам. Я использую ниже библиотеки. Кто-то, рассматривающий вариант 2/3, может найти его полезным.
Вариант 3!.
В общем, я успешно использовал вариант 2, но теперь для простоты склоняюсь к варианту 3. Генерация статических HTML-страниц с помощью скрипта сборки и их обслуживание на одном из сверхбыстрых серверов, специализирующихся на обслуживании статических страниц, очень заманчиво (вариант 2).