А ВОТ ТЕПЕРЬ ПАБЛИК
Vladimir
Ну до какой то степени, да
Vladimir
Также как и с любым другим стандартом
A
это очень большая проблема. JavaEE яркий тому пример, там уже абстрации ради абстракций и полнейшее говно на выходе. хотя начиналось все так же, хотели чтобы разрабам было якобы проще
Чет мы какую-то разную JavaEE видели, видимо. С JavaEE как раз обратная проблема - в ней столько всего всякого разного, что это всё за раз среднему проекту, в котором нет каких-нибудь распределенных транзакций на несколько дата-сторов, не надо. Поэтому, внезапно, JPA, который входит в JavaEE спецификацию, используют частенько отдельно.
A
Или те же сервлеты. Как бэ... ну надо внимательно сначала глянуть на сервлеты, а потом на express, например
A
Не всё, конечно, так радостно и сочно в JavaEE мире, да и сейчас редко кто пишет труъ корпоративный софт
A
Но я очень сильно не согласен, что вся EE это абстракции ради абстракций.
A
Ну, и к слову, современные сервлеты в реинкарнации 3+ вполне себе втаскивают по скорости.
A
Ладно, у меня вопрос. MERN стек. Сбегали в монгу, получили документ, теперь хотим отдать его в виде JSON-а клиенту.
A
Только я не хочу отдавать весь документ и в таком виде, как он пришёл. Мне надо _id переименовать в id. Пару полей скрыть, пару сгенерировать из базовых (например full name слепить из firstName и lastName), и еще у меня в документе есть массив с какой-нибудь херней, у которой надо сделать то же самое для каждого вложенного объекта.
A
В общем чем view реализовать-то?)
A
У меня сейчас доморощенная библиотека с декларативным синтаксисом, быстрая как сотона, но она кое-чего не умеет. Есть подозрение, что это классный, но велосипед
A
Вопрос. Чего люди для этого используют?
A
Да, я скорее true way ищу. Оно у меня вот так сейчас выглядит
A
Я понимаю, что я реализовал что-то вроде XSLT для JSON.
A
Наверняка я не первый такой
Таймураз
Я иначе вижу работу с данными. В монге ты хранишь данные, а модель данных заворачиваешь в функцию, которая преобразовывает твой объект в то, что тебе нужно
A
А модель данных у нас кто?
Таймураз
Я работаю в mongoose, но, честно говоря, не использую весь его функционал. Думаю разобраться с нативным драйвером
Таймураз
А модель данных у нас кто?
Не модель данных, а документ
A
Я тоже mongoose использую. Он мне вытаскивает документ, который, ну типа, со схемой. На нем у меня есть куча всяких методов - и статических и методов инстанса
A
С помощью них я делаю бизнес-логику
A
Ребята вопрос на засыпку, adwords api кто нибудь юзает?
A
И вот после того как сделал - у меня остаётся, ну вот в случае с примером на картинке, школа. Но в ней есть уйма всего, что участвует в бизнес-логике, но что пользователю не нужно, или нужно в другом виде. Соответственно это я отрезаю это или еще как-то модифицирую. Понятно, что это может быть просто функция, в которой я императивно всё нужное делаю.
A
A V, [21 февр. 2017 г., 20:30]: поясни там апи разные если смотреть свои данные или чужие через oauth2 а то зашел и потерялся ссылка на ссылке туда сходи зарегай дев токен
A
мультиаккаунт и прочее
A
Монгус жирнее нативщины Буду копать monk и нативный
а чем мешает? может у меня какой-то самый популярный кейс, но я вижу, что mongoose покрывает все юзкейсы, плюс вся бизнес-логика в него и легла. Что весьм удобно. Плюс всякие радости из коробки, типа descriminators
A
У монгузы можно просто toJSON метод переназначить
это неправильно, у меня в разных местах разные представления данных. Хотя бы по уровням доступа
A
Да и вообще, слой http view уносить в модель странная затея
Таймураз
это неправильно, у меня в разных местах разные представления данных. Хотя бы по уровням доступа
Так когда ты достаешь объект- ты также можешь пароль достать и остальные данные. Он удаляет их только когда к JSON-у приводится объект
Таймураз
JSON только для view и нужен У монгуза модель можно к обычному объекту привести, можно в JSON
A
Не, смотри, есть у меня школа. В ней классы. Вот самый главный админ в ней видит хуеву гору всяких настроек (http endpoint #1), а простой смертный только название (http endpoint #2). Или ты предлагаешь держать всю логику доступа в одном toJSON ?
A
Это я еще не признался в том, что вьюхи-то на самом деле активные и весьма бодро спрашивают базу, потому что в ряде случаев происходит еще более глубока денормализация данных, чтобы клиент лишний раз не бегал в API) Но это другая история, да)
Таймураз
Я от другого пляшу В toJSON я удаляю то, что нигде не должно быть видно. А то, что зависит от бизнес-логики, разруливается уже самой бизнес логикой
A
Так этих "нигде" может быть несколько. Или у тебя оно всегда одно?
Таймураз
Всю логику доступа в toJSON неправильно перемещать
Таймураз
Например, никто не должен получить хеш и соль Они удаляются в toJSON
Таймураз
Нигде в проекте версию документа не нужно знать- тоже удаляется
Таймураз
Можно было на уровне монгузы удалить версию, вроде как, но как ты говорил, это другая история)
Alan
за компом приходится сидеть еще и печатать (
snatvb
ваще жесть
snatvb
Lev
Читать доки на английском
snatvb
зачем нам инструкция, мы сами разберемся ©
snatvb
тыб конкретнее задал вопрос
snatvb
а то не понятно даж как ответить
A
За джангу не скажу, но вообще, это весьма странно.
A
Питон как бы.. славиться своей прямолинейностью
A
За что, собственно, многими и любим
A
Эдакий простой и понятный инструмент в форме змеи
A
Но опять же, джанга - она же convention over configuration.
A
И вроде с ормом сразу, и моделями
A
А express это только http
Таймураз
экспресс прост как пробка. Не столько важно знать сам экспресс, сколько понимать веб. Коа- другая архитектура, чуть сложнее (только чуть), основная сложность- коа 2 под капотом имеет промисы
A
А сложность - это обязательное условие?)
Таймураз
Сложность в понимании промисов и в том, как это влияет на архитектуру приложения
Таймураз
Вчера ты уже выдал await на стрелочную функцию, значит сложность есть)
Таймураз
Не советую начинать с koa работать прям сейчас, так как нужно кучу всего перед этим изучить
A
Сложность в понимании промисов и в том, как это влияет на архитектуру приложения
нет никакой сложности в понимании промисов, не морочь человеку голову. обычный паттерн.
Таймураз
Таймураз
нет никакой сложности в понимании промисов, не морочь человеку голову. обычный паттерн.
Объективно- да. Субъективно- это все нужно изучить и понять влияние одного паттерна на другой
Завтра
A
Джаваскрипт
Завтра
Рафик, как тебя хватат на 2 чата одновременно
Таймураз
В принципе, если ты работал уже с промисами, то что-то да можно найти Скину чуть позже, если найду
Завтра
Что ж тебе все так тяжко заходит
Таймураз
https://habrahabr.ru/post/301126/ по полкам разложено
Завтра
Я всей этой фигне за неделю, наверное, научился
Таймураз
Прочесть и осмыслить- разные вещи
Таймураз
Ну прям разжевывать тебе никто не будет) Не понимаешь- гуглишь
Завтра
Я сам так же писал
Завтра
На jQuery только