Симорошка, ты там пингуй если что, скоуп накидать, сторей расписать..

Симорошка,

Homyachiha-Stacie, дааааа, от подобного рода помощи я бы не отказалась! Вот я тут накидываю кусочки чего-то: workflowy.com/s/tmH.vk4IX5ObVF

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

Homyachiha-Stacie, хах, я только кинулась дописать про сообщества, а оно уже там!)))) Да, о них нужно подумать на начальных этапах.

Симорошка, это я совладала с тулой))
Моя любимая работа прям. Завтра и ноут с собой возьму, будет явно удобнее)

Homyachiha-Stacie,

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

ооооо, смотрите, какой раритетище, он еще старее и страшнее нашего: members.diaryland.com/edit/
и до сих пор кто-то пишет.

Симорошка,

омг, это как люди, у которых до сих пор есть аська!

Симорошка, кстати, Хель говорит, что если будете делать новый проект, она с удовольствием как графический дизайнер поучаствует с точки зрения дизайнов)

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

ну и пара вопросов более общих:
- зачем вообще кто-то будет ими пользваться когда все уже твиттят в фейсбуке и выкладывают котиков в инстаграмм? Только для старой аудитории?
- старые дайри загибаются потому что люди начали уходить ( ну или может потому что новые перестали приходить ) - что побудит этих людей пользоваться новыми?

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

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

bogolt, зачем нужно рендерить на клиенте?
я собираюсь использовать рендер на сервере.
про бэкенд думали?
экспресс и монго

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

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

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

а я то думал по старинке PHP

К сожалению, Express не может самостоятельно обрабатывать формы в URL-кодировке. Тут нам на помощь придёт ранее установленный пакет body-parser.
вы бы еще на ассемблере сайты писали, лооол

Reuniko,можешь сформулировать более конструктивный комментарий?

вы бы еще на ассемблере сайты писали, лооол
А что не так с сайтами на асме? Если нужна производительность то подходят любые методы.

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

Если посчитать нагрузку - 10к человек всего, предположим 8к ежедневно, ну и предположим из них 5к в час. 1 Час = 3600 секунд - меньше двух запросов в секунду - справится любая черепаха. Но по-моему это весело выживать на минимально возможном железе.
Поэтому я бы для этой цели взял что-нибудь быстрое и компилируемое, ну например го или даже плюсы, базу в стиле sqlite и выложил бы это на ДО за 5 долларов в месяц. Они дают 250 оперативки и 20 гигов ссд диска. Зато полноценная виртуалка, делай что хочешь.

Note: sqlite собирать без поддержки многопоточности, и реалзовать ее средствами языка - или вообще ставить все запросы в очередь - их ведь будет реально очень очень мало.

По бд - имхо NoSql тут будет не самым лучшим выбором ( или я просто не понимаю как ).
Вот смотри - в монге ты сделаешь допустим документ на каждого пользователя. И документ на каждый пост.
Пользователь - хранит все свои посты ( ну ссылки на них ).
Пока все хорошо, но вот добавляются комментарии. Где их хранить?

Если их хранить в документе топика - неудобно выгребать пользователю списки своих комментариев. Если их хранить в пользователе - неудобно в посте их получать. Можно хранить ссылки на них и там и там, но тогда уже начинается дублирование данных - неприятно.
Дальше добавляются приватные сообщения. У них схожая проблема. Хранить их допустим в документе пользователя отправителя - но тогда чтобы собрать все входящие сообщения - нужно будет каждый раз ворошить всех друзей.
Короче я хз, наверное это будет работать, но я не вижу тут приемуществ NoSql баз.
Я сам стараюсь выбирать NoSql в одном из двух случаев -
- тут надо дико широко масштабироваться а все знают какая боль это делать с реляционными базами
- нужен доступ только по одному ключу

Если же делать на реляционной базе то можно сделать чуть удобнее:
таблицы: - юзер - пост - коммент - сообщение

ну и дальше - простейшие запросы тебе возвращают сразу же нужные данные.

Эх, мне и самому было бы возможно интересно вписаться, но у меня тут и так завал, а впереди все станет еще напряженнее. Но может и смогу чуть помочь.

Добавлю к вышесказанному про монгу
stackoverflow.com/questions/2655251/mongodb-tra...
Если коротко - в тот момент когда понадобится обновить и несколько документов атомарно ( то есть в транзацкии ) начнутся серьезные проблемы. Вот почему большинство no-sql лучше просто рассматривать как key-value хранилище, без взаимосвязей между документами. Если же начинаются связи ( а тут их будет немало ) то нужно брать либо реляционную бд либо другую NoSql в которой это реализованно на приемлемом уровне.

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

Но по-моему это весело выживать на минимально возможном железе.
У каждого свои способы веселиться.

Объясню свою мотивацию выбора всех этих "новомодненьких" технологий.
1. Я терпеть не могу PHP и всё, что похоже на "старый веб", у меня негативный импринт на это дело.
2. Самое важное для меня - чтобы разработка была максимально приятная и удобная. Для меня это означает использование джаваскрипта везде, где можно, и современных решений, которые делают работу легче и продуктивнее. Так больше шансов, что из этого что-то хорошее получится, а проект не будет брошен на середине, потому что код вышел из-под контроля.
3. Так как я занимаюсь почти этими же штуками на работе, я могу использовать уже имеющийся сет знаний, что делает задачу проще. К тому же это поспособствует моему лично карьерному росту.
4. Мне нужно приобщить Николу к реальному проекту, который утилизирует те знания, которые ищут местные работодатели, и которые уже у него краешком есть.

Для соц сетей никакие существующие толком не годятся =))
Вон фейсбук выкатил свою бд для этого дела. Но это все не имеет особого смысла - вся эта информация важна для тех кто ожидает высоких нагрузок.

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

bogolt,

bogolt, читаю вот про то, как использовать нереляционки в социальных сайтах, довольно интересно:
docs.microsoft.com/en-us/azure/cosmos-db/social...
github.com/mongodb-labs/socialite/blob/master/d...

Симорошка, аааа, я хочу быть как-то причастен к новому сайту, если я могу что-то сделать, считай меня в команде

Пробежал глазами доку по Азур, и неприятно удивился тому какую лажу там впаривают. Вначале утверждают для что отображения одного поста в SQL версии бд нужно 8 джойнов ( пост + юзер + комменты + картинки + аудио + изображения + лайки + те кто лайкал ) а потом волшебным образом вытаскивают эту запись из своей NoSQL как 1 документ.
Правда при этом картинки, изображения и аудио они впихнули как голые ссылки ( в общем в sql можно было бы также сделать ) а про комментарии и лайки почему-то всеже вынесли отдельно, поэтому все равно придется это все как-то объединять.

Но впрочем у меня к MS очень предвзятое отношение.

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

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

Если одна из целей - изучить и разобраться, я бы посоветовал что-то не супер-модное, зато достаточно универсальное и часто требуемое в разных местах.

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

Bats, спасибо! я сообщу, как у нас начнет что-то конкретное оформляться (хотя бы первый прототип).

PHP7 —

Ты молодец, я всячески поддерживаю)