API на основе электронных таблиц для создания MVP.

Что делать, если у вас есть сайт, который нужно время от времени обновлять? Это не блог, поэтому вам не нужен Wordpress. Также не стоит создавать индивидуальную серверную часть. Говоря языком разработчиков, мы могли бы подумать об удаленном хостинге данных для хранения данных для полудинамических веб-сайтов или приложений.

Взгляните на приложение с уведомлением ниже - вы захотите централизовать свою информацию где-нибудь в облачном хранилище, чтобы вы могли обновлять и синхронизировать со всеми клиентскими приложениями (будь то веб-сайты / мобильные приложения).

Решение по умолчанию может размещаться на вашем собственном сервере с Django или Node.js в качестве конечной точки для предоставления API. Но разве это не кажется излишним?

Представьте себе Wordpress для приложений

Было бы неплохо, если бы было что-то похожее на Wordpress, которое можно было бы использовать в качестве CMS (системы управления контентом) для вашего приложения - что-то с простым графическим интерфейсом для редактирования и обновлением серверной части.

Почему он не может быть простым и удобным?

Вместо того, чтобы настраивать выделенный сервер для конечной точки API для некоторых относительно статических данных, есть несколько более простых вариантов:

  1. Размещение статического файла JSON на S3;
  2. Использование имитации службы API для имитации конечной точки

Однако для обновления данных с конечной точки требуются дополнительные усилия разработчика.

Следовательно, когда мы думаем над вопросом:

«Каким должно быть следующее поколение API-интерфейсов?»

Почему данные API не могут быть такими же интуитивно понятными, как мы их видим? Нашим решением был APITable, который выполняет одно действие: Таблица → JSON API.

Мы считаем, что APITable может выполнять правильную работу в качестве простой конечной точки API по нескольким причинам:

Не нужно изучать базы данных

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

Мгновенный API

Развертывание не требуется. Как только вы обновите таблицу, данные будут немедленно доступны вашим клиентам API. Вы также можете добавлять / удалять столбцы прямо из редактора электронной таблицы.

SDK не требуется

JSON API удобен для разработчиков. Независимо от того, является ли ваш интерфейс веб-сайтом, мобильным приложением для iOS или Android - вы можете найти удобный синтаксический анализатор для преобразования данных, возвращаемых API, в нужный вам тип данных.

Вы также можете напрямую curl API напрямую . Вам не нужно придерживаться какого-либо SDK для этой простой службы API.

Редактируйте данные прямо в таблицах

Нам нравятся данные в табличной форме по следующим причинам: у вас есть быстрый обзор; то, что вы редактируете, - это то, что вы получаете - вам не нужно переходить на подслои, чтобы редактировать детали продукта, просто делайте это прямо в таблице.

Вызовы

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

Мы использовали Skygear в качестве серверной части нашего приложения, которая служит облачной базой данных наших таблиц.

Сохранять и загружать записи партиями

Во-первых, загрузка большой таблицы из облака в одном запросе может вызвать медленную скорость загрузки (при тестировании мы использовали гонконгский набор данных о автобусных маршрутах и ​​тарифах, который содержит более 1000 строк записей). Мы также учли, что пользователям API могут не понадобиться все данные одновременно. Поэтому мы ввели разбиение на страницы как в электронной таблице, так и в конечной точке API.

Также возникает проблема с производительностью при сохранении нескольких строк. Рассмотрим случай копирования и вставки данных в электронную таблицу, что вызывает обновление нескольких строк. Если мы будем сохранять построчно, потребуется много запросов, чтобы сохранить все обновления записей. Следовательно, при сохранении за сценой есть уловка:

  • Различать, обновляется ли строка или удаляется;
  • Каждую добавленную строку необходимо обновить в очереди, а те, которые нужно удалить, - в другую очередь;
  • Сохраните обновление и удалите очередь пакетом.

После того, как мы собрали записи, осталось всего 2 запроса.

Простая авторизация

Возможно, вы не хотите, чтобы ваш API был доступен всем. Мы также разработали для людей, которым требуется аутентификация для API. Более простой и эффективный способ - запросить действительный токен при доступе к конечной точке.

Чтобы управлять тем, кто может получить доступ к данным из вашей таблицы, вы может создавать и отзывать токен на панели управления APITable.

Для кого создан APITable?

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

  • Инди-разработчики: быстрое прототипирование приложений для демонстрации возможности удаленного извлечения данных;
  • Стартапы: создание MVP или простых приложений для новостной ленты;
  • Тестировщики QA: хранение фикстуры данных или фиктивных данных для целей тестирования приложений.

APITable - это бесплатный проект с открытым исходным кодом, доступный на GitHub, который мы сделали, чтобы помочь инди-разработчикам и даже тем, кому просто нужна удобная конечная точка API. Дайте нам знать, что вы думаете!

Создаете приложение? Наши бесплатные инструменты разработчика и бэкэнд с открытым исходным кодом упростят вашу работу.