Atlas как сервис

Перевод материала подготовлен в рамках курса "NoSQL".

Приглашаем также всех желающих на двухдневный интенсив «MongoDB Map-Reduce Framework».
— Темы 1 дня: CRUD-операции; фильтрация по полям; sort, skip, limit; запросы по поддокументам.
— Темы 2 дня: концепция map-reduce; концепция pipeline; структура и синтаксис агрегации; стадия $match; стадия $group; стадия $lookup.

Многие наши клиенты предоставляют своим командам разработчиков доступ к MongoDB как к сервису. Разработчики могут запросить экземпляр базы данных MongoDB и получить строку для подключения и учетные данные за считаные минуты. Переходя на использование MongoDB Atlas, наши клиенты заинтересованы и в том, чтобы дать своим разработчикам соответствующий уровень обслуживания.

В Atlas есть очень мощный уровень управления для предоставления кластеров. Однако в крупных организациях, где работают тысячи разработчиков, не всегда целесообразно предоставлять такому количеству людей прямой доступ к этому интерфейсу. Цель этой статьи — показать, как можно использовать API-интерфейсы Atlas для предоставления доступа к MongoDB как к сервису, когда MongoDB работает под управлением Atlas.

В частности, мы продемонстрируем способ создания интерфейса, предлагающего разработчикам набор вариантов для создания экземпляра базы данных MongoDB. Чтобы упростить себе задачу, рассмотрим, как предоставить разработчикам набор вариантов памяти и хранилища для настройки кластера. Прочие параметры, например выбор провайдера облачных услуг и региона, мы рассматривать не будем. Мы также расскажем о том, как добавлять метки к кластерам Atlas, так как эта функция не поддерживается в пользовательском интерфейсе Atlas. Для примера мы добавили метку для описания кластера.

Архитектура

Хотя API-интерфейсы Atlas можно вызывать непосредственно из клиентского интерфейса, мы решили использовать трехуровневую архитектуру. Ее преимущества заключаются в следующем:

• возможность ограничивать доступную функциональность по мере необходимости;

• возможность упростить API-интерфейсы, доступные разработчикам клиентских частей приложений;

• возможность тонкой настройки защиты конечных точек API.

• Мы могли бы воспользоваться другими функциями серверной части, например триггерами, интеграцией с Twilio и т. д.

Конечно же, для размещения среднего уровня мы выбрали Realm.

Реализация

Серверная часть

API Atlas

API-интерфейсы Atlas обернуты в набор функций Realm.

По большей части все они вызывают API Atlas следующим образом (здесь мы взяли для примера getOneCluster):

/*
* Gets information about the requested cluster. If clusterName is empty, all clusters will be fetched.
* See https://docs.atlas.mongodb.com/reference/api/clusters-get-one
*
*/
exports = async function(username, password, projectID, clusterName) 
{

	const arg = {
		scheme: 'https',
		host: 'cloud.mongodb.com',
		path: 'api/atlas/v1.0/groups/' + projectID +'/clusters/' + 
clusterName,
		username: username,
		password: password,
		headers: {'Content-Type': ['application/json'], 
'Accept-Encoding': ['bzip, deflate']},
		digestAuth:true
	};

	// The response body is a BSON.Binary object. Parse it and return.
	response = await context.http.get(arg);
	return EJSON.parse(response.body.text());
};

Исходный код каждой функции размещен на GitHub.

API MiniAtlas

Следующий шаг — представление функций как конечных точек, которые может использовать клиентская часть. В качестве альтернативы мы могли бы вызывать функции с помощью Realm Web SDK, но мы решили придерживаться протокола REST; он более знаком нашим веб-разработчикам.

Используя функционал сторонних сервисов, мы разработали следующие 6 конечных точек:

Далее представлен исходный код конечной точки getClusters (примечание: имя пользователя и пароль извлекаются из констант Value и Secret):

/*
* GET getClusters
*
* Query Parameters
*
* None
*
* Response - Currently all values documented at https://docs.atlas.mongodb.com/reference/api/clusters-get-all/
*
*/
exports = async function(payload, response) {

	var results = [];

	const username = context.values.get("username");
	const password = context.values.get("apiKey");
	projectID = context.values.get("projectID");

	// Sending an empty clusterName will return all clusters.
	var clusterName = '';

	response = await context.functions.execute("getOneCluster", username, password, 
	projectID, clusterName);
	results = response.results;

	return results;
};

Исходный код каждого веб-хука размещен на GitHub.

При сохранении веб-хука генерируется URL-адрес, который служит конечной точкой для API:

Защита конечных точек API

Только аутентифицированные пользователи могут выполнять функции, представленные конечными точками API. При вызове API необходимо передавать заголовок авторизации с действительным идентификатором пользователя. Конечная точка пропустит этот идентификатор через следующую функцию:

exports = function(payload) {
	const headers = context.request.requestHeaders
	const { Authorization } = headers
	const user_id = Authorization.toString().replace(/^Bearer/, '')
	return user_id
};

MongoDB Realm имеет несколько встроенных провайдеров аутентификации, включая доступ для анонимных пользователей, доступ по комбинации электронная почта / пароль, доступ по ключам API, а также аутентификацию OAuth 2.0 через Facebook, Google и Apple ID.

Для этого примера мы решили использовать сервис Google OAuth — прежде всего потому, что он уже интегрирован с провайдером единого входа, который мы используем в нашей компании.

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

Клиентская часть

Клиентская часть реализована на JQuery и размещена в Realm.

Аутентификация

С помощью MongoDB Stitch Browser SDK клиент предлагает пользователю войти в учетную запись Google (если вход еще не выполнен) и передает учетные данные пользователя Google в StitchAppClient.

let credential = new stitch.GoogleRedirectCredential();
client.auth.loginWithRedirect(credential);

Идентификатор пользователя, который необходимо использовать при отправке запроса API в серверную часть, можно получить из StitchAppClient следующим образом:

let userId = client.auth.authInfo.userId;

Затем его можно включить в заголовок при вызове API. Вот пример вызова API createCluster:

export const createCluster = (uid, data) => {
	let url = `${baseURL}/createCluster`

	const params = {
		method: "post",
		headers: {
			"Content-Type": "application/json;charset=utf-8",
			...(uid && { Authorization: uid })
		},
		...(data && { body: JSON.stringify(data) })
	}

	return fetch(url, params)
	.then(handleErrors)
	.then(response => response.json())
	.catch(error => console.log(error) );
};

Все вызовы API можно посмотреть в файле webhooks.js.

Полезный совет

Нам принесли большую пользу командные рабочие пространства в Postman. Этот инструмент позволяет совместно разрабатывать серверные API и проверять их работоспособность.

Заключение

Этот прототип создан для демонстрации возможностей, о которых, надеемся, вы уже получили представление! Основа решения есть. Как ее использовать, решаете вы сами.

Узнать подробнее о курсе "NoSQL"

Участвовать в двухдневном интенсиве «MongoDB Map-Reduce Framework»