Почему?

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

Не понял :)

Не успел дописать ) Понравилось, это важно

Даже для реста нужно накручивать drf. Я уже не говорю про graphql или web sockets.

Разочаровался в тех кто делает фронтенды на реакте? ) Просто надо фулстекеров брать чтобы бы могли и бекенды и фронтенды делать )

вот я про это где-то весной говорил)

Или просто хороших фронтов

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

SPA не эксперименты, это давно де-факто стандарт для нормально UX. GraphQL действительно молодая технология, но делать web интерфейсы в духе Django/rails это прошлый век. Мой посыл в том, что для стартапа нужен mvp с интерфейсом, следовательно бойлеоплэйт для ui идёт первее бэкэнда. На каком-нибудь firebase можно ооочень далеко зайти, следовательно бэкэнд можно отложить ещё до лучших времён. Но если не хочется vendor lock-in и хочется сразу сделать апишечку, то ок, нам нужен свой бэкэнд. Для каких-то случаев Django подходит лучше, для каких-то хуже. Тут наверное действительно зависит от имеющегося опыта с конкретной технологией.

Или просто хороших фронтов

Потому, что front end это тяжело и сложно (если это не лэндинг). А круды любой дурак может писать, поэтому кажется, что бэкэндеры лучше :)

Сорян ребята, соскучился по холиворам за праздники :)

Потому, что front end это тяжело и сложно (если это не лэндинг). А круды любой дурак может писать, поэтому кажется, что бэкэндеры лучше :)

тебя бы на дебаты жс вс питон :) там примерно те же доводы были, но в обратную сторону - мол писать фронтенд много ума не надо

тебя бы на дебаты жс вс питон :) там примерно те же доводы были, но в обратную сторону - мол писать фронтенд много ума не надо

он и был )

?

а, по никнеймам не узнаю :)

тебя бы на дебаты жс вс питон :) там примерно те же доводы были, но в обратную сторону - мол писать фронтенд много ума не надо

Я там был, лол) топил за js)

тогда всё сходится)

Js заразен, съедает все вокруг :р

тогда всё сходится)

https://secure.meetupstatic.com/photos/event/1/2/b/c/highres_465724796.jpeg

ого закрепы наконец-то стали видны в веб-версии телеграма о_0

Я вот тут два года сидел на питоно-бекенде, сейчас трогаю vue за причинные места - пока что мне всё (или почти всё) кажется проще (кроме жс и обилия библиотек :))

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

Потому, что front end это тяжело и сложно (если это не лэндинг). А круды любой дурак может писать, поэтому кажется, что бэкэндеры лучше :)

ну если бекенды тупые и играю роль прокси для БД, то пора задуматься про БД c graphql и хранимками на js (и удобным деплоем). А еще в идеале чтобы она рассматривала клиентов как вьюшки от БД и сама синкала. Вот это норм будет.

ну если бекенды тупые и играю роль прокси для БД, то пора задуматься про БД c graphql и хранимками на js (и удобным деплоем). А еще в идеале чтобы она рассматривала клиентов как вьюшки от БД и сама синкала. Вот это норм будет.

так firebase ж

Я вот тут два года сидел на питоно-бекенде, сейчас трогаю vue за причинные места - пока что мне всё (или почти всё) кажется проще (кроме жс и обилия библиотек :))

Ну, чем больше стэйта тем сложнее становится. Добавить ещё постоянно меняющийся дизайн и требования и ваще грустно :/

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

ну если бекенды тупые и играю роль прокси для БД, то пора задуматься про БД c graphql и хранимками на js (и удобным деплоем). А еще в идеале чтобы она рассматривала клиентов как вьюшки от БД и сама синкала. Вот это норм будет.

Угу, я примерно так и хочу. Но н рынке пока все закрытое, типа firebase. Есть ещё rethink но у них пока все не ясно.

Угу, я примерно так и хочу. Но н рынке пока все закрытое, типа firebase. Есть ещё rethink но у них пока все не ясно.

rethink же больше нет ?

rethink же больше нет ?

Компании нет, но есть oss проект

Угу, я примерно так и хочу. Но н рынке пока все закрытое, типа firebase. Есть ещё rethink но у них пока все не ясно.

я еще вот этих ребят жду https://edgedb.com/

так firebase ж

он умеет обеспечивать хранение данных пользователей из определенных стран (не только Россия) в датацентрах ех самых стран?

он умеет обеспечивать хранение данных пользователей из определенных стран (не только Россия) в датацентрах ех самых стран?

а зачем вы задачи кластеризации на бд вешаете ?

тебя бы на дебаты жс вс питон :) там примерно те же доводы были, но в обратную сторону - мол писать фронтенд много ума не надо

Приоритет интерфейса никак не говорит о сложности программирования на js. Более того, там звучала несколько другая мысль. Она относилась не к языку, а к тем кто на нём пишет.

так firebase ж

Couch тоже

а зачем вы задачи кластеризации на бд вешаете ?

FIrebase это же платформа, которая позади имеет БД в облаке, так?

он умеет обеспечивать хранение данных пользователей из определенных стран (не только Россия) в датацентрах ех самых стран?

Couch и Mongo

ну если бекенды тупые и играю роль прокси для БД, то пора задуматься про БД c graphql и хранимками на js (и удобным деплоем). А еще в идеале чтобы она рассматривала клиентов как вьюшки от БД и сама синкала. Вот это норм будет.

Mongo

FIrebase это же платформа, которая позади имеет БД в облаке, так?

Ага, емнип там нельзя регионы выбирать

Couch и Mongo

Mongo недавно научилась еще и нормально апдейты засылать

жесть какая

Mongo недавно научилась еще и нормально апдейты засылать

а то вспоминается как был реализован meteor, страшно даже ))

Mongo недавно научилась еще и нормально апдейты засылать

Там вообще кайф.;) И у них есть свой облачный сервис. Да ещё и с готовыми каркасами приложений.

я так понимаю тут все пилят второй гугл

что такое нужно

а то вспоминается как был реализован meteor, страшно даже ))

Meteor прикидывался репликой монги, и понимал её внутренний протокол для синхронизацией

?

Couch и Mongo

Особенно в связки с pouchdb, но я пока не пробовал.

я так понимаю тут все пилят второй гугл

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

что такое нужно

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

Meteor прикидывался репликой монги, и понимал её внутренний протокол для синхронизацией

Ну meteor вообще не самая изящная штука

Да я понимаю что требование есть, но можно же это сделать на Application layer это все, если сильно хочется

Ну meteor вообще не самая изящная штука

Зато идея богатая ) были бы более модульными, глядишь бы жили

Особенно в связки с pouchdb, но я пока не пробовал.

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

а то как обычно берется хайповая БД и все ждут что она решит все проблемы

но так к сожалению не работает :)

Зато идея богатая ) были бы более модульными, глядишь бы жили

Так живут же, вроде. Плохо, наверное, но живут?

Да я понимаю что требование есть, но можно же это сделать на Application layer это все, если сильно хочется

Сделать на уровне приложения можно всё, но зачем, если инструмент может из коробки не хуже?

в том что он хуже. Заточенное ПО под конкретную задачу всегда лучше.

а то как обычно берется хайповая БД и все ждут что она решит все проблемы

Как раз монгу брали и решали все проблемы сами, но они начали самые частые закрывать движком

Да я понимаю что требование есть, но можно же это сделать на Application layer это все, если сильно хочется

Как? это можно сделать на уровне application layer если у гугла нет железных мощностей в РФ?

в том что он хуже. Заточенное ПО под конкретную задачу всегда лучше.

Тогда и делай на приложении. Но часто оно нормально и так

На счет монги я уже все свои позиции в монгочате высказал и все остались при своих :)

Как? это можно сделать на уровне application layer если у гугла нет железных мощностей в РФ?

причем тут гугл ?

На счет монги я уже все свои позиции в монгочате высказал и все остались при своих :)

Удивительно. В монгочате не приняли позицию, что монга неочень? Быть такого не может.

=)

причем тут гугл ?

я упоролся и был уверен что это очередное облачное решение на тему baas

Удивительно. В монгочате не приняли позицию, что монга неочень? Быть такого не может.

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

Ну и монга да, была не очень. Особенно когда в проде какая нить 2.2 и все хором орут “а вы должны были взять новую версию”, и напрямую миграцию сделать нельзя

Ну и монга да, была не очень. Особенно когда в проде какая нить 2.2 и все хором орут “а вы должны были взять новую версию”, и напрямую миграцию сделать нельзя

Это какое-то нытье, а не конструктив, извините.

Даже для реста нужно накручивать drf. Я уже не говорю про graphql или web sockets.

а зачем нужен graphql?

а зачем нужен graphql?

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

Это какое-то нытье, а не конструктив, извините.

справедливости ради, у монги вылечили все баги репликации только в 3.4

справедливости ради, у монги вылечили все баги репликации только в 3.4

Заметьте не я это сказал

но имхо, graphql сложноват для маленьких проектов

справедливости ради, у монги вылечили все баги репликации только в 3.4

справидливости ради, джаваскиптом стало нормально пользоваться только с ES6 ?

так и живем ?

Заметьте не я это сказал

https://aphyr.com/posts/322-jepsen-mongodb-stale-reads

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

мне это кажется решением несуществующей проблемы.

https://medium.com/@pakaldebonchamp/rest-is-the-new-soap-97ff6c09896d

мне это кажется решением несуществующей проблемы.

ну смотри, мне кажется разделение на frontend/backend пережитком (конечно до какого-то размера и сложности проекта). один варик, это иметь fullstack разработчиков, которые будут сами себе пилить апишки (все по классике, но надо либо людей пишущих на нескольких языках, либо все писать на js :)), либо дать фронтендерам самим лазить в базу и на данный момент GrpahQL вариант с самым лучшим потенциалом.

вот кстати пост по теме http://tonsky.me/blog/the-web-after-tomorrow/

если уж сильно хочется реста напрямую в бд то есть же postrest

=)

А что плохого в нескольких языках?

ну смотри, мне кажется разделение на frontend/backend пережитком (конечно до какого-то размера и сложности проекта). один варик, это иметь fullstack разработчиков, которые будут сами себе пилить апишки (все по классике, но надо либо людей пишущих на нескольких языках, либо все писать на js :)), либо дать фронтендерам самим лазить в базу и на данный момент GrpahQL вариант с самым лучшим потенциалом.

есть еще хороший стек clojure + clojurescript

имхо получше js и там и там )

есть еще хороший стек clojure + clojurescript

Вот тоже присматриваюсь))

есть еще хороший стек clojure + clojurescript

согласен, разве что чуть сложнее будет команду собрать

вот кстати пост по теме http://tonsky.me/blog/the-web-after-tomorrow/

>Always fresh data. >Instant response. >Handle network failures. >No low-level connection management, retries, deduplication. бггг... это какие-то адовые мечты. сети сложны и ломаются самым причудливым образом и единственный кто может сказать ок или не ок - это приложенька.

>Underlying library should take care of the details. я девочка, я хочу платье

>Underlying library should take care of the details. я девочка, я хочу платье

это же про "завтра" )

http://lgbtkvartal.com/uploads/monthly_2017_02/large.58b12ba545ec8_-.jpg.0f20d4875206318dcc947f94e92c2db5.jpg

те же вебсокеты, несмотря на то что они по tcp не дают гарантий доставки )))

>Underlying library should take care of the details. я девочка, я хочу платье

глядишь и правда захочешь платье )

=)))

глядишь и правда захочешь платье )

reliable, gay friendly

А pipenv хорош, почти как yarn :p Правда venv по прежнему через pyvenv создаю.

не сыроват?

А pipenv хорош, почти как yarn :p Правда venv по прежнему через pyvenv создаю.

Есть неприятные минусы Ну и pyup не могут прикрутить его поддержку

не сыроват?

да вроде пока все норм

И он .bash_profile не подхватывает, включает дефолтный shell после запуска