Как создать платформу, подобную Facebook, на Google App Engine?

Я заинтересован в создании платформы на Google App Engine, где одно главное приложение предоставляет общие функции нескольким дочерним приложениям (веб-порталам).

Основное приложение:

  • Предлагает общие функции социальных сетей
  • Общая база пользователей
  • Взаимодействует с использованием API веб-сервисов

Дочерние приложения (веб-порталы):

  • Подключается к главному приложению для использования базы данных пользователей и функций социальных сетей.
  • Использует локальную бизнес-логику для локальных функций

Мой план дизайна:

  1. Основные и дочерние приложения будут отдельными приложениями в GAE Appspot (для удобства управления).
  2. Все будут общаться через REST/JSON?
  3. Я включу выставление счетов для всех приложений, чтобы ничто не противоречило политике использования Google.
  4. Будет использовать SSL для входа в Master App, позже использовать токен (cookie) для дальнейших взаимодействий

Может ли кто-нибудь любезно определить риски и предложить какие-либо улучшения?


architecture rest google-app-engine restful-authentication soa
person charming30    schedule 07.03.2011    source источник
comment
Не делайте этого с SSL, это как бы противоречит цели.   -  person Fibericon    schedule 07.03.2011
comment
Я не понимаю, почему вы думаете, что отношения Мастера и Ребенка облегчат управление. Могли бы вы объяснить? Если вы откажетесь от этого, то 1., 2. и 3. станут неактуальными. А 4. ни туда, ни сюда.   -  person Glenn    schedule 07.03.2011
comment
@Fibericon: Поскольку все мои приложения являются частными, и мне нужно защитить их данные, я думаю о SSL. Это будет медленнее? Как вы думаете, есть лучший способ? Пожалуйста, предложите.   -  person charming30    schedule 07.03.2011
comment
@Glenn: Вы правы, все они являются просто приложениями, зависящими от некоторых других веб-сервисов, которые предлагают свои функции.   -  person charming30    schedule 07.03.2011
comment
@Glenn: Превратить всю эту платформу в единое приложение было бы очень сложно и неуправляемо. Вот почему я думаю разбить их на отдельные приложения, чтобы их можно было легко обновлять и управлять ими.   -  person charming30    schedule 07.03.2011
comment
Являются ли эти «дочерние приложения» независимыми, как приложения для Facebook? Кто-нибудь может разработать? Если нет, вы должны сделать их частью основного приложения — если вы считаете, что это неуправляемо, вам просто нужно научиться лучше управлять большой кодовой базой.   -  person Nick Johnson    schedule 08.03.2011
comment
@Nick: Я частично согласен с вами, но если у вас есть что-то вроде Yahoo Movies, Yahoo Finance, Yahoo Mail, все как дочерние приложения, которые используют основные службы Yahoo, такие как членство, то как лучше всего построить такое решение на GAE, помня об их TOS?   -  person charming30    schedule 08.03.2011
comment
@Nick: Хорошо, если дочерние приложения предназначены для сторонних разработчиков, в таком случае подойдет ли эта архитектура?   -  person charming30    schedule 08.03.2011
comment
@charming30 В случае с Yahoo * это отдельные сайты, которые просто используют общий брендинг и аутентификацию, поэтому отдельные приложения вполне разумны. Аналогичным образом, в случае приложений, написанных сторонними разработчиками, вы должны предоставить какой-то внешний протокол, но он должен работать для любого веб-приложения, а не только для приложений App Engine.   -  person Nick Johnson    schedule 08.03.2011

Ответы (2)


arrow_upward
1
arrow_downward

Вашу концепцию «главный/дочерний» будет сложно поддерживать, возникнут проблемы с межсайтовым скриптингом и, что наиболее важно, она будет полностью противоречить условия использования для объединения нескольких приложений в одно.

4.4. Вы не можете разрабатывать несколько Приложений для имитации или работы в качестве одного Приложения или иным образом получать доступ к Сервису таким образом, чтобы избежать взимания платы.

person Chris Farmiloe    schedule 07.03.2011
comment
... как было указано, когда ОП специально задал этот вопрос о TOS в своем предыдущем вопросе SO. - person Wooble; 07.03.2011
comment
Будет ли применяться это правило, даже если включить выставление счетов во всех приложениях? Я не собираюсь избегать комиссий, мне просто нужна распределенная система, которую я могу поддерживать и обновлять самостоятельно. - person charming30; 08.03.2011
comment
Да, боюсь, что да. Даже если это непреднамеренно, вы будете избегать комиссий, поскольку каждое приложение поставляется с собственным включенным или отключенным выставлением счетов по бесплатным квотам. - person Chris Farmiloe; 08.03.2011

arrow_upward
1
arrow_downward

Вы можете использовать несколько версий приложения (определенные в app.yaml) для развертывания разных баз кода в одном и том же поддомене appspot.com и доступа к ним, например http://app1.myapp.appspot.com, http://app2.myapp.appspot.com для "версий" app1 и app2. У вас даже может быть одна версия, работающая на Java, а другая — на Python. Все они будут использовать одно и то же хранилище данных, хотя при необходимости вы сможете использовать пространства имен для их разделения.

Что касается распределенного характера предложенной вами архитектуры, я бы посоветовал внимательно изучить API графов Facebook и API Twitter. Они оба используют oAuth для аутентификации/авторизации и уже имеют проверенную реализацию того, чего вы пытаетесь достичь.

person guigouz    schedule 08.03.2011
comment
Звучит очень хорошо, я думаю, что это также может соответствовать Google TOS, поскольку все приложения будут зависеть от одной квоты. Я мог бы использовать пространства имен для разделения данных для различных приложений. Большое спасибо за это. - person charming30; 10.03.2011
comment
Спасибо, я рассмотрю API Facebook и Twitter, как было предложено. - person charming30; 10.03.2011