Closed nin-jin closed 5 years ago
Предлагаешь их в репозиторий пересохранить или на иной фотохостинг?
Вообще, можно сделать, чтобы инфа о спикерах, выступлениях и митапах хранилась как issue на гитхабе. У меня так habhub сделан: https://github.com/nin-jin/HabHub
@nin--jin Предлагаю хранить в репозитории, чтобы они грузились с того же хоста, что и сайт. Чтобы уменьшить задержки на получение DNS от CDN, где они будут храниться.
Вариант с ишьями мне не нравится, ибо они не очень подходят для справочной информации по формату:
оффтоп: @nin-jin зачем у тебя два гитхаб аккаунта?..
Если редактировать эти файлы прямо в репозитории, то так и так можно сломать всё. Разве что добавить валидацию при деплое. Зато при использовании issue можно не париться на тему загрузки файлов - просто вставил как-нибудь при редактировании. Гитхаб всё это пересохранит к себе. И останется лишь показать. Насчёт закрытости - наоборот удобно. Если открыта, значит заполнение еще не закончено. Как закрыли - оно попадает на сайт.
@nin-jin Сломать можно везде, согласен. И валидировать всё равно где-нибудь можно, срезая лишнее. Ишьи - это потенциальное место для уязвимостей, кстати. Поэтому срез всего лишнего надо будет очень хорошо проработать. Спасибо гитхабу за проксирование картинок - в чьи-то серверные логи юзер уже не попадёт, но чую подвох в этом плане всё равно. Думаю, этот вопрос можно проработать, так что теоретически я не против размещения спикеров в ишьях. Мне нравится аргумент на счёт времени на проработку. Таким образом можно после создания ишьи просить спикеров перепроверить актуальность слайдов и прочего, что мы захотим в ишье описывать.
@mike1pol нужно твоё внимание. Глянь этот реквест, плиз. Как тебе идея хранить инфу о спикерах в ишьях этой репы, а не в файловой системе?
А, ну да, мы же не хотим привязываться к гитхабу, ибо его блокируют. Мы-то куда оперативнее меняем айпишники при блокировке :-)
Я за хранение и валидацию данных в репе, так как issue ненадежная штука, может кто-то удалит и т.д., плюс придумываю dsl для issue
Я думаю стоит денормализовать данные, объединив их в одно дерево - так проще будет редактировать руками. Правда информация о докладчике будет дублироваться. С другой стороны, эта информация для разных докладов может быть нужна разная. Например, если бы я делал доклад про взлом, то я бы приложил фото в хакерском образе, а в описании сделал бы акцент на своём опыте именно в этой области.
Звучит логично, но я бы подумал над структурой данных, хочется для докладчиков сделать отдельную страницу на которой можно посмотреть всех докладчиков, с инфой о выступлениях и т.д.. Можно сделать общий список докладчиков, но при этом дать возможность переопределять описание докладчика и фото для конкретного митапа
Для хранения данных можно попробовать взять https://console.graph.cool/ или https://firebase.google.com
console.graph.cool даже на собственном сайте нагрузку не держит. firebase.google.com я как-то пробовал использовать - так и не прошёл этот квест до конца.
А много ли докладчиков выступало больше одного раза?
Есть которые выступали более 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.
Это-то понятно. Вопрос в том на сколько это массовое явление. Просто если у человека всего один доклад, то страница доклада с информацией о докладчике и страница докладчика с информацией о докладах - содержат одну и ту же информацию.
Я тут больше про наследование говорил, т.е. у каждого спикера есть страница, но в каждом митапе можно переопределить фото спикера и описание, но не обязательно. Мы можем попробовать договориться о структуре данных и я могу накидать бек на prisma-graphql, а для фронта сделаем spa + ssr
Но тогда стоит начать с выведения сущностей
Вопрос в том на сколько это массовое явление
@nin-jin это массовое явление. Посмотри в Airtable в таблице Speakers в столбце Events.
prisma то и дело таймаутится. Где ты такие сервисы берёшь? :-)
Вкратце о том, за что я люблю GraphQL:
Ее не обязательно у них разворачивать, для прототипирования призма подходит отлично, ты чисто пишешь схему и все, а потом уже можешь сам накрутить бек на это
Тогда я вообще не вижу смысла в этой прослойке. Схему можно и на 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
GraphQL достаточно строгий, и потом это можно будет развивать, причем UI не будет завязан на сервер, а только на API, в репозитории все хранить можно в файлах, но это не очень хорошо
@nin-jin @mike1pol мне кажется, обсуждение уже не связано с изначальной целью пул реквеста - «выпиливание экспорта из Airtable». Моё мнение: пул реквест можно принять в текущем виде, а ваше обсуждение про формат базы стоит перенести в новую ишью (и лучше ишью, чем чат, ибо ишья почти = документация).
Ишью создать не забудьте :D
@nin-jin как смотришь на то, чтобы фотки спикеров хранить в сайте, а не тянуть с airtable? Иначе переезд нельзя считать полноценным и едва ли в нём тогда есть смысл.
В остальном для меня всё выглядит ок.