Выпиливание экспорта из Airtable в пользу человекочитаемого конфига в репозитории.

fogrew commented 5 years ago

@nin-jin как смотришь на то, чтобы фотки спикеров хранить в сайте, а не тянуть с airtable? Иначе переезд нельзя считать полноценным и едва ли в нём тогда есть смысл.

В остальном для меня всё выглядит ок.

nin-jin commented 5 years ago

Предлагаешь их в репозиторий пересохранить или на иной фотохостинг?

Вообще, можно сделать, чтобы инфа о спикерах, выступлениях и митапах хранилась как issue на гитхабе. У меня так habhub сделан: https://github.com/nin-jin/HabHub

fogrew commented 5 years ago

@nin--jin Предлагаю хранить в репозитории, чтобы они грузились с того же хоста, что и сайт. Чтобы уменьшить задержки на получение DNS от CDN, где они будут храниться.

Вариант с ишьями мне не нравится, ибо они не очень подходят для справочной информации по формату:

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

оффтоп: @nin-jin зачем у тебя два гитхаб аккаунта?..

nin-jin commented 5 years ago

Если редактировать эти файлы прямо в репозитории, то так и так можно сломать всё. Разве что добавить валидацию при деплое. Зато при использовании issue можно не париться на тему загрузки файлов - просто вставил как-нибудь при редактировании. Гитхаб всё это пересохранит к себе. И останется лишь показать. Насчёт закрытости - наоборот удобно. Если открыта, значит заполнение еще не закончено. Как закрыли - оно попадает на сайт.

fogrew commented 5 years ago

@nin-jin Сломать можно везде, согласен. И валидировать всё равно где-нибудь можно, срезая лишнее. Ишьи - это потенциальное место для уязвимостей, кстати. Поэтому срез всего лишнего надо будет очень хорошо проработать. Спасибо гитхабу за проксирование картинок - в чьи-то серверные логи юзер уже не попадёт, но чую подвох в этом плане всё равно. Думаю, этот вопрос можно проработать, так что теоретически я не против размещения спикеров в ишьях. Мне нравится аргумент на счёт времени на проработку. Таким образом можно после создания ишьи просить спикеров перепроверить актуальность слайдов и прочего, что мы захотим в ишье описывать.

fogrew commented 5 years ago

@mike1pol нужно твоё внимание. Глянь этот реквест, плиз. Как тебе идея хранить инфу о спикерах в ишьях этой репы, а не в файловой системе?

nin-jin commented 5 years ago

А, ну да, мы же не хотим привязываться к гитхабу, ибо его блокируют. Мы-то куда оперативнее меняем айпишники при блокировке :-)

mike1pol commented 5 years ago

Я за хранение и валидацию данных в репе, так как issue ненадежная штука, может кто-то удалит и т.д., плюс придумываю dsl для issue

nin-jin commented 5 years ago

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

mike1pol commented 5 years ago

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

mike1pol commented 5 years ago

Для хранения данных можно попробовать взять https://console.graph.cool/ или https://firebase.google.com

nin-jin commented 5 years ago

console.graph.cool даже на собственном сайте нагрузку не держит. firebase.google.com я как-то пробовал использовать - так и не прошёл этот квест до конца.

А много ли докладчиков выступало больше одного раза?

mike1pol commented 5 years ago

Есть которые выступали более 3х раз On 18 Jun 2019, 12:29 +0300, nin-jin notifications@github.com, wrote:

console.graph.cool даже на собственном сайте нагрузку не держит. firebase.google.com я как-то пробовал использовать - так и не прошёл этот квест до конца. А много ли докладчиков выступало больше одного раза? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

nin-jin commented 5 years ago

Это-то понятно. Вопрос в том на сколько это массовое явление. Просто если у человека всего один доклад, то страница доклада с информацией о докладчике и страница докладчика с информацией о докладах - содержат одну и ту же информацию.

mike1pol commented 5 years ago

Я тут больше про наследование говорил, т.е. у каждого спикера есть страница, но в каждом митапе можно переопределить фото спикера и описание, но не обязательно. Мы можем попробовать договориться о структуре данных и я могу накидать бек на prisma-graphql, а для фронта сделаем spa + ssr

mike1pol commented 5 years ago

https://www.prisma.io/

mike1pol commented 5 years ago

Но тогда стоит начать с выведения сущностей

fogrew commented 5 years ago

Вопрос в том на сколько это массовое явление

@nin-jin это массовое явление. Посмотри в Airtable в таблице Speakers в столбце Events.

nin-jin commented 5 years ago

prisma то и дело таймаутится. Где ты такие сервисы берёшь? :-)

nin-jin commented 5 years ago

Вкратце о том, за что я люблю GraphQL:

mike1pol commented 5 years ago

Ее не обязательно у них разворачивать, для прототипирования призма подходит отлично, ты чисто пишешь схему и все, а потом уже можешь сам накрутить бек на это

nin-jin commented 5 years ago

Тогда я вообще не вижу смысла в этой прослойке. Схему можно и на OSQL налабать:

create class Object
create property Object.title string
create property Object.description string

create class Meetup extends Object
create property Meetup.numb integer
create property Meetup.begin datetime
create property Meetup.translation string

create class Speech extends Object
create property Speech.duration string

create class Speaker extends Object
create property Speaker.photo string
create property Speaker.slides string
create property Speaker.video string

create property Meetup.speech linklist Speech
create property Speech.meetup link Meetup

create property Speech.speaker link Speaker
create property Speaker.speech linkset Speech

mike1pol commented 5 years ago

GraphQL достаточно строгий, и потом это можно будет развивать, причем UI не будет завязан на сервер, а только на API, в репозитории все хранить можно в файлах, но это не очень хорошо

fogrew commented 5 years ago

@nin-jin @mike1pol мне кажется, обсуждение уже не связано с изначальной целью пул реквеста - «выпиливание экспорта из Airtable». Моё мнение: пул реквест можно принять в текущем виде, а ваше обсуждение про формат базы стоит перенести в новую ишью (и лучше ишью, чем чат, ибо ишья почти = документация).

fogrew commented 5 years ago

Ишью создать не забудьте :D

piterjs / piterjs.org

Выпиливание экспорта из Airtable в пользу человекочитаемого конфига в репозитории. #9