Какие задачи фрустрируют?

Какие задачи фрустрируют?

все задачи отличные от запрос-сходилвбазу-ответ

да, просто по аналогии с yii2 привёл, сорри. Имею ввиду, какой паттерн используется для управления моделями типа как ORM, и какие инструменты "общепринятые" реализуют подобное. Вообще, приложухи современные не чисто же на голом экспрессе пишутся. Там есть модели всякие и т.п.

я обычно mvc встречал поэтому также делаю

да, просто по аналогии с yii2 привёл, сорри. Имею ввиду, какой паттерн используется для управления моделями типа как ORM, и какие инструменты "общепринятые" реализуют подобное. Вообще, приложухи современные не чисто же на голом экспрессе пишутся. Там есть модели всякие и т.п.

orm sequilize

я думаю тебе лучше начать с express + mysql + sequilize + react/vue

Ещё есть ddd но это для тех кто любит когда больно и тебе не платят за это.

я думаю тебе лучше начать с express + mysql + sequilize + react/vue

?

Всем асинхронных снов ?

а то ещё нахрен заблокирует и не проснёшься

Когда строишь посредственный рест да Но если шаг влево или вправо начинаешь частенько чесать репу

а вообще возможно построить сложный сервис только на rest?

я не понимаю))

а вообще возможно построить сложный сервис только на rest?

вы задаете вопрос из разряда "можно ли построить здание только с помощью чертежей"?

??

обмажутся своим rest'ом

вы задаете вопрос из разряда "можно ли построить здание только с помощью чертежей"?

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

обмажутся своим rest'ом

И крудят друг друга в сервисы

я опять тупой вопрос задал?)

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

Rpc?

Рест это же про ресурсы и тд, так?

http://json-schema.org/

Рест это же про ресурсы и тд, так?

это формат запроса списка объектов и их изменение

Rpc?

мне бы такой стандарт, чтобы им как и restом обмазаться можно было. стильно модно молодежно чтобы)

мне бы такой стандарт, чтобы им как и restом обмазаться можно было. стильно модно молодежно чтобы)

Модно - graphql

Модно - graphql

слишком попсово. oracle odata, вот это стиль

http://json-schema.org/

вроде похоже)

Модно - graphql

да, давно хотел в своих сервисах на трех человек попробовать)

обмажутся своим rest'ом

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

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

вебсокеты - это постоянное соединение с сервером. rest - это стандартные http запросы

rest тупо описывает формат url

вебсокеты - это постоянное соединение с сервером. rest - это стандартные http запросы

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

надеюсь правильно сказал)

интерфейсное приложение - это что имеется в виду?

приложение на react?

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

чтобы держать куеву тучу соединений, когда это не надо

приложение на react?

к примеру да

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

хотя я вебсокетами не пользовался.. я их через сторонние библиотеки использую типа firebase

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

смысл вашей фразы похож на почему используют зеленое вместо квадратного)

смысл вашей фразы похож на почему используют зеленое вместо квадратного)

почему же, одно и то же по сути, общение клиент-сервер.

рест по сути - это формат url для api. сокеты - это способ браузера передать данные на сервер

рест по сути - это формат url для api. сокеты - это способ браузера передать данные на сервер

ок, "рест-клиент" и "вебсокет-клиент" на реактовом приложении

ок, "рест-клиент" и "вебсокет-клиент" на реактовом приложении

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

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

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

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

я как-то раз так и сделал все збс работало

я как-то раз так и сделал все збс работало

я почему интересуюсь, я сейчас тоже как раз так делаю.

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

потому что апи может быть частично или полностью публичным

потому что апи может быть частично или полностью публичным

да, но речь не об api для системных публичных каких-то вызовов, а чисто для общения сервера с пользовательским приложением (реакт к примеру)

я почему интересуюсь, я сейчас тоже как раз так делаю.

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

а держать кучу соединений открытыми постоянно это норм?

оно не сдохнет?

а держать кучу соединений открытыми постоянно это норм?

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

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

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

да, но речь не об api для системных публичных каких-то вызовов, а чисто для общения сервера с пользовательским приложением (реакт к примеру)

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

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

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

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

я недавно чат с техподдержкой на firebase реализовал. там таких вопросов с сокетами или не сокетами вообще нет

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

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

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

Всмысле? как это не безопастно?

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

на ум сразу пришло base64 ?

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

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

Всмысле? как это не безопастно?

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

Парни,есть литература или видео по js+MongoDB?может есть проверенная инфа

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

почитайте про firebase

Парни,есть литература или видео по js+MongoDB?может есть проверенная инфа

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

почитайте про firebase

ок

ок

firebase пример с чатом

ERROR: S client not available

и все равно это не серебрянная пуля

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

ну как бы для этого и есть идентификация/авторизация и разграничение доступа.

и все равно это не серебрянная пуля

согласен

на ум сразу пришло base64 ?

сохранение файла с сервера на конечное устройство, а не с устройства на сервер.

ну как бы для этого и есть идентификация/авторизация и разграничение доступа.

мало ли, отвалится что-нибудь ) а клиенты будут знать, что есть такая щель, типа /api/users/get, значит есть и /api/users/delete

сохранение файла с сервера на конечное устройство, а не с устройства на сервер.

decode base64 ?

мало ли, отвалится что-нибудь ) а клиенты будут знать, что есть такая щель, типа /api/users/get, значит есть и /api/users/delete

от ошибок никто не застрахован, но такая ситуация маловероятна

decode base64 ?

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

ну потеряется пара юзеров и что? заново зайдут)

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

это уже утрирование )

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

применит пегого дудочника

это уже утрирование )

да, но это банальная вещь, которую лучше делать через API и без «твоего активного участия»

да, но это банальная вещь, которую лучше делать через API и без «твоего активного участия»

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

применит пегого дудочника

сразу вспоминается эпичная последняя серия 1-го сезона с расчётом количества времени, чтобы удовлетворить всех участников в зале ?

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

а в чём?) Ты можешь все сделать без REST’а, но в какой-то момент с большей вероятностью тебе его все равно придется прикручивать

и на REST меньше ресурсов надо, чем держать все на сокетах (как ты сам выше уточнил)

ресурсов сервера

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

и на REST меньше ресурсов надо, чем держать все на сокетах (как ты сам выше уточнил)

сокеты еще и не всеми браузерами поддерживаются

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

кейс - отдать по запросу файл, который генерируется на ходу с БД

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

если файлы привязаны к id, то наверное в каких-то случаях имеет

сокеты еще и не всеми браузерами поддерживаются

ну я на примере «жирных» socket.io

ну я на примере «жирных» socket.io

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

изи

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

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

срач!

кто подкинет на вентилятор?))

кто подкинет на вентилятор?))

ща: Двух пробелов на отступ, хватит всем!