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

В итоге кода меньше

Хотя по честному, могли бы ещё меньше

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

+1

Но у меня ожидания, что будет как с Flux = текущий Relay лишь первая итерация. Уже посматриваю на Apollo.

за пару месяцев я уже несколько раз поймал багу на этапе компиляции

Relay это мода. Не станет он мейнстримом потому что сложен

скорее всего да

но GraphQL должен

кстати.. graphQL database еще никто не написал?

Последнее время пишу исключительно с использованием flow, никогда не чувствовал себя лучше

коннекты скорее всего ест

я обычно к postgres прикручиваю

к какой-нибудь mongodb

Ну мы обсуждали что GraphQL это xpath для json. То есть в общем-то догоняем стандарты двадцатилетние

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

сложно представить

https://github.com/solidsnack/GraphpostgresQL

ага. я эту видел

но это всеравно sql

Reindex.io под капотом держит MongoDB

я не люблю такое "чтобы само"

мне не горит, просто интересно :)

поэтому даже не тогал reindex

Да нормальные пацаны

пацанты то может быть и норм

Мне в целом нравится тенденция, что сейчас всё автоматизируется в разработке

Декларативность привела к тому, что меньше пишешь, больше думаешь

Плюс масштабируемость таких паттернов высокая

Но сложнее читать и понимать, что происходит

Если речь о GraphQL, мне кажется большинству он не нужен

Наоборот

Я помню jQuery-километры кода

Паш, ты ведь тоже помнишь? ;)

Сейчас с React всё крайне удобно читается и понимается

Ну это проблему решил реакт, тут не спорю. Но доступ к данным - более деликатная тема

Сопровождение на порядки проще, но требует уже куда более фундаментальных архитектурных принципов

Ну вот например у тебя реляционная СУБД - пробрасывать запросы с клиента никто никогда не мешал

Но проблема с безопасностью

SQL вообще был языком для менеджеров и далёких от IT людей :)

Если заменить SQL на GraphQL, приннципиально ничего не изменится

SELECT * FROM users

Это было в англоязычном мире, у нас бы это выглядело: ВЫБРАТЬ * ИЗ пользователей

1С

Большое приложение React/Redux в итоге состоит из набора однотипных операций

Command / Query

Ну в этом нет ничего декларативного, наоборот - простая архитектура за счет кучи бойлерплейта. И ничего плохого в этом нет

Сообщество пока не решило проблему с этим, но движение в этом направление как раз мы и видим)

По сути React = это конфигурция

(реальный bottleneck = анимация)

фронтэнд - это просто)

ахах

Как два лендинга сверстать

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

Так и есть, вопрос затрат. Большой проект на jQuery и большой проект на React = два разных бюджета на сопровождение. Но если бюджеты в ИТ понятие гибкое, то время часто критично и в этом плане введение и взаимозаменяемость разработчиков в React просто космос.)

Да не вопрос, я тоже считаю что лучше реакта ничего нет. Но все таки чат по бэкэнду, сложности фронтенда не идут с бэкэндам ни в какое сравнение

Фронтэнд в крайнем случае можно целиком выкинуть и переписать)

:)))

лол

бекенд фигня

если что — перехал на другую бд

За Великий Бэкенд

тем более микросеивися

Понеслось

пиши — не хочу

переехал, а данные остались(

говно — выкинул микросервис и переписал на го

Ты еще про PaaS и Длкеры скажи

пф, мигрировать данные проще чем прикрутить select к форме

Или афира перед сном почитал, а потом кошмары снятся

Да не проще, примерно также

ну, да, сравнимо

чем там эти бекендеры занимаются — сходить в БД и json-чик отдать

Я чет не врубаюсь, чат по node.js, тут должны быть только бэкэндеры

А тут как обычно - реакт реакт реакт

каждый js разраб считает себя бекендером :)

Каждый JS немножко бэкенд

Каждый бэкенд немножечко JS