если есть сущность like(id, post_id, author_id) стоит ли хранить тут информацию об авторе поста чтобы потом проверить, что автор не может лайкать себе пост ИЛИ стоит делать еще один запрос в базу, чтобы узнать автора поста и сравнить с юзером, отправившим лайк ИЛИ лучше сделать leftJoin?

Оффтоп: А запрещать лайкать самому себе - это бизнес требование?

Оффтоп: А запрещать лайкать самому себе - это бизнес требование?

да, бизнес требование

А лайк не добавляет в закладки?

нет, просто сохраняется запись о лайке

да, бизнес требование

Лично я бы сделал, наверное, CONSTRAINT-ом в postgres

Лично я бы сделал, наверное, CONSTRAINT-ом в postgres

на клиент надо будет отправлять информацию о том, может ли текущий пользователь лайкать свой пост

Лично я бы сделал, наверное, CONSTRAINT-ом в postgres

вообще вот это норм пытаться вставить заведомо кривые данные и валидировать постгресом? звучит как простой быстрый и надежный вариант, но побочкой идет килотонна логов уровня ERROR даже без хайлоада если

на клиент надо будет отправлять информацию о том, может ли текущий пользователь лайкать свой пост

Если лайков планируется сильно больше кол-ва постов- лучше запросить но айдишнику новость, чем еще одно поле добавлять

post < like^(2/3)- делать запрос и кешировать

вообще вот это норм пытаться вставить заведомо кривые данные и валидировать постгресом? звучит как простой быстрый и надежный вариант, но побочкой идет килотонна логов уровня ERROR даже без хайлоада если

Не знаю, если честно, не сталкивался пока с таким хайлоудом. Исхожу я из того, что по требованиям юзер не может лайкнуть свой контент. Т.е. в БД ни при каких условиях не должны добавиться неконсистентные данные. В случае использования вне-БД-проверок, такое возможно.

Если лайков планируется сильно больше кол-ва постов- лучше запросить но айдишнику новость, чем еще одно поле добавлять

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

Не знаю, если честно, не сталкивался пока с таким хайлоудом. Исхожу я из того, что по требованиям юзер не может лайкнуть свой контент. Т.е. в БД ни при каких условиях не должны добавиться неконсистентные данные. В случае использования вне-БД-проверок, такое возможно.

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

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

На все действия три запроса сверху

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

автор поста неизвестен, если ты его не передаешь вместе c id

автор поста неизвестен, если ты его не передаешь вместе c id

К нам приходит пользователь, есть его айдишник Запрашиваем пост Совпадают автор поста и пользователь- это и есть автор

К нам приходит пользователь, есть его айдишник Запрашиваем пост Совпадают автор поста и пользователь- это и есть автор

пользователь ставит лайки на 10 постов, среди них 2 его, как без допольнительных обращений в базу отсечь самолайк? только таскать автора поста с постом или констрейнтом в БД

К нам приходит пользователь, есть его айдишник Запрашиваем пост Совпадают автор поста и пользователь- это и есть автор

Я в этом случае вообще делаю SELECT * FROM posts WHERE user_id=%1 (упрощенно, конечно же)

пользователь ставит лайки на 10 постов, среди них 2 его, как без допольнительных обращений в базу отсечь самолайк? только таскать автора поста с постом или констрейнтом в БД

А смысл в схеме новости автора не хранить?

пользователь ставит лайки на 10 постов, среди них 2 его, как без допольнительных обращений в базу отсечь самолайк? только таскать автора поста с постом или констрейнтом в БД

это же можно сделать множеством способов включая странный способ от tonsky на crdt

это же можно сделать множеством способов включая странный способ от tonsky на crdt

а конкретнее можно?

хранить set лайкнувших и анлайкнувших и выводить число фильтром

А смысл в схеме новости автора не хранить?

post(id, author_id, text) like(id, author_id, post_id) Любой пользователь делает лайк на любой пост, нужно каждый раз проверять принадлежит ли пост этому пользователю При выводе поста нужно выводить флаг, может ли пользователь лайкать пост

хранить set лайкнувших и анлайкнувших и выводить число фильтром

в памяти? он потенциально может быть очень большого размера

post(id, author_id, text) like(id, author_id, post_id) Любой пользователь делает лайк на любой пост, нужно каждый раз проверять принадлежит ли пост этому пользователю При выводе поста нужно выводить флаг, может ли пользователь лайкать пост

а ты автора поста не отправляешь что ли? сравниваешь юзера текущего и автора, один и тот же - лайкать не надо

в памяти? он потенциально может быть очень большого размера

В редисе?

а ты автора поста не отправляешь что ли? сравниваешь юзера текущего и автора, один и тот же - лайкать не надо

как в нормальный REST добавить автора? например PUT /posts/{id}/like, обязательным тело делать с ссылкой на автора, а если автора подсунули левого?

а ты автора поста не отправляешь что ли? сравниваешь юзера текущего и автора, один и тот же - лайкать не надо

хм, хороший вопрос. Я к посту отправляю информацию post(id, text, author(id, first_name, last_name)) в виде графа. А id - это глобальный id из relay-js

как в нормальный REST добавить автора? например PUT /posts/{id}/like, обязательным тело делать с ссылкой на автора, а если автора подсунули левого?

это при сохранении, а при получении поста можно флаг сразу пихать, или вообще оставить это на фронт

В редисе?

ну так это другой вопрос, там у автора изначально только БД вроде, если задаться ограничениями то можно искать варианты да

это при сохранении, а при получении поста можно флаг сразу пихать, или вообще оставить это на фронт

ну это бизнес-требование, его можно будет легко обойти (это плохо)

ну это бизнес-требование, его можно будет легко обойти (это плохо)

при сохранении проверять все равно надо

при сохранении проверять все равно надо

так изначально вопрос как это делать оптимально

ну так есть 2 задачи - првоерка при сохранении и вывод инфы на фронте

с одной стороны сохранять в like информацию об авторе поста -- это дублирование данных с другой не сохранять данные - это постоянно делать два раза join

Всем привет! Начинаю работать над крупным проектом на Redux, использую ноду как прослойку для серверного рендеринга, нормализации данных для клиента, и т.д. У кого был опыт нормализации данных, подготовки стейта для клиента при получении данных из внешних источников? Поделитесь опытом?

Какие библиотеки используете? Или что-то самописное? Плюсы и минусы, с которыми столкнулись?

Всем привет! Начинаю работать над крупным проектом на Redux, использую ноду как прослойку для серверного рендеринга, нормализации данных для клиента, и т.д. У кого был опыт нормализации данных, подготовки стейта для клиента при получении данных из внешних источников? Поделитесь опытом?

отправляй REST на клиент как есть, там уже нормализуют через библиотеку https://github.com/paularmstrong/normalizr

Спасибо

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

Я как раз фронтендер, и насчет производительности раньше не сильно заморачивался. Не знаю, насколько операции нормализации на сервере могут сказаться на ней.

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

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

Понял, спасбио

На микросервис json запросы лучше делать axios? Fetch?

Как потестить авторизацию через GitHub, если сервер на localhost? Что мне указать в Callback URL?

На микросервис json запросы лучше делать axios? Fetch?

Что подходит тем и делай

Как потестить авторизацию через GitHub, если сервер на localhost? Что мне указать в Callback URL?

Эм, localhost? :)

Эм, localhost? :)

ну мысль была такая, но решил сначала уточнить ))

Не надо бояться экспериментировать ;)

Парни

Плохая практика делать динамические страницы на node?

Вернее на экспрессе

а какие ты хочешь выводить?

При запросе на site.ru/bugs выводить запрос к БД

При запросе на site.ru/bugs выводить запрос к БД

Why not? Ты хочешь для этого запилить Web App на React+Redux+Saga+GraphQL?

парни а можете объяснить как работает event loop или дать пару ссылок на источники?

Why not? Ты хочешь для этого запилить Web App на React+Redux+Saga+GraphQL?

React+Redux+Saga+GraphQL - это максимум на лендос

парни а можете объяснить как работает event loop или дать пару ссылок на источники?

https://www.youtube.com/watch?v=8aGhZQkoFbQ

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

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

в описание посмотри

ох. сорри и спасибо!

https://m.youtube.com/watch?v=8cV4ZvHXQL4&feature=youtu.be

https://www.youtube.com/watch?v=8aGhZQkoFbQ

Перевод.

Ещё почитать про libuv

Попробовать с ней поиграть в сях

Знай свой инструмент: Event Loop в libuv https://habrahabr.ru/post/336498/

там есть куски из libuv, довольно неплохая статья

Вопрос достаточно обширной тематики, но задам. Какие существуют хорошие практики по логированию в проекте? Интересует анализ, хранение (критические ошибки и т.д.).

Вопрос достаточно обширной тематики, но задам. Какие существуют хорошие практики по логированию в проекте? Интересует анализ, хранение (критические ошибки и т.д.).

Лог в JSON, для хранения ElasticSearch+Fluentd+Kibana.

там есть куски из libuv, довольно неплохая статья

это очень хорошая статья

Плюсую по поводу статьи.

Лог в JSON, для хранения ElasticSearch+Fluentd+Kibana.

В JSON - Winston?

Хотя Winston вроде как тяжеловат.

В JSON - Winston?

pino

Bunyan ещё

Bunyan ещё

benchBunyan*10000: 1355.229ms benchWinston*10000: 2226.117ms benchBole*10000: 291.727ms benchDebug*10000: 445.291ms benchLogLevel*10000: 322.181ms benchPino*10000: 269.109ms

спасибо за перевод и за ссылки!

pino

Почему раньше не видел ?

pino

Спасибо!

Лог в JSON, для хранения ElasticSearch+Fluentd+Kibana.

Спасибо!

benchBunyan*10000: 1355.229ms benchWinston*10000: 2226.117ms benchBole*10000: 291.727ms benchDebug*10000: 445.291ms benchLogLevel*10000: 322.181ms benchPino*10000: 269.109ms

Да ладно :) Рили, микробенчмарки для логгера?)

Почему раньше не видел ?

ну мало кого тревожит скорость логгера, меня тревожит, поэтому я всегда такие пакеты вижу и ищу

ну мало кого тревожит скорость логгера, меня тревожит, поэтому я всегда такие пакеты вижу и ищу

Именно поэтому не использовал Winston, свои "наработки" (в кавычках) были.

Спасибо!

Если хочешь, можешь переодически простукивать мне в ЛС, я всё никак не собируюсь выложить на GitHub свой конфиг для EFK.

Если хочешь, можешь переодически простукивать мне в ЛС, я всё никак не собируюсь выложить на GitHub свой конфиг для EFK.

Понял, спасибо!

Именно поэтому не использовал Winston, свои "наработки" (в кавычках) были.

это норм, иногда намного лучше свой написать

Pino достаточно молодой вроде, надо будет попробовать)

Ой, да шо там писать...)

Ой, да шо там писать...)

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

Pino достаточно молодой вроде, надо будет попробовать)

он еще и браузер поддерживает, отличный проект и очень толковый подход у ребят

Сейчас уже не айс делать лог в файл, пусть этим внешняя аппа занимается (pm2, docker). Остаётся форматирование, но это такое... Про браузерную поддержу да, не подумал, но не думаю, что это нечто фатально сложное, верно?

Сейчас уже не айс делать лог в файл, пусть этим внешняя аппа занимается (pm2, docker). Остаётся форматирование, но это такое... Про браузерную поддержу да, не подумал, но не думаю, что это нечто фатально сложное, верно?

сложно сделать с минимальными накладными и чтобы умел что надо

Окей, после еды полистаю исходники этого вашего pino)

Окей, после еды полистаю исходники этого вашего pino)

Лучше до еды

Лучше до еды

Хм) Пожалуй) На самом то деле ничего особенного, обычный древненький код. Сериалайзер да pretty-print утилка.

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

как запустить ноду в интернет