Это только звучит очень удобно, на самом деле это только увеличивает time to market при росте как команды, так и сложности проекта.
Ваша проблема решается вынесением общего кода в пакеты и обязательного соблюдения семантического версионирования
Вы не правильно понимаете акроним devOps.
Это не какой-то сверх человек вроде сис админа, который еще и в коде понимает. Это набор практик для интеграции разработки и эксплуатации, что бы уменьшить проблемы в сопровождении релизов до стабильной стадии. Т.е разработчик, когда пишет код должен задумываться как этот код будет работать в бою и как его эксплуатировать.
Если под лучше вы предполагаете быстрее — то на текущем этапе разницу увидеть сложно.
Изначально переезд на монгу обуславливался очень простым горизонтальным масштабированием (репликация, auto failover, шардирование), причем по сравнению с pg/mysql прям из коробки. И это все настраивается «по щелчку пальцев»
Бэкенд. Повелитель бизнес-логики, наш бэкенд будет небольшим Flask-приложением. Данные (наши карточки) будем хранить в популярном key-value хранилище MongoDB
Что значит не очень «идеологично»? Есть ряд конкретных ограничений, которые и определяют этот подход как REST. То, что вы туда добавили ресурсы и вербальность (GET POST PUT) это уже ваша надстройка, которая к этому стилю не имеет никакого отношения. И если у frontend'щиков появляются проблемы с огромным кол-вом обращения к API из-за этих ресурсов, чтобы начинить один компонент. То тут дело в некомпетентности backend разработчика, который путает понятия.
===
REST — это архитектурный подход предполагающий клиент-серверное взаимодействие, БЕЗ хранения промежуточного состояния. Нет состояния, нет проблем, есть куча фишек вроде кеширования и слоистости. Это не про ресурсы /user:id user/:id/comment/:id, не про GET-PUT-DELETE… как думают многие и откуда растёт миф.
Не знаю почему habrahabr.ru/post/334182/#comment_10329372 словил столько минусов. Вообще-то он прав. С чего вы взяли, что в REST нельзя сделать мутацию GET-запросом? ru.wikipedia.org/wiki/REST
По поводу множества запросов — тоже полнейший бред. REST никак не стандартизирует это. Вы вполне можете создать endpoint /getFilm который вернет фильм с жанрами, актерами и т.д.
И да, в таком виде «GraphQL — сам подмножество REST».
Вообще-то в js классов нет и не было. То что вы называете классами в ES2015 — это синтаксический сахар, под капотом в себе кроет старые добрые прототипы.
var eventMixin = {
on: function (eventName, handler) {},
off: function (eventName, handler) {},
trigger: function (eventName) {}
};
//конструктор (модель)
var Book = function () {};
Book.byObject = function () {};
var bookService = (new function () {
var self = this,
books = [];
//добавляем примесь событий сюда
self.add = function (data) {
var newBook = Book.byObject(data);
books.push(newBook);
self.trigger('add', newBook);
};
//... и т.д. CRUD
//так же сюда все xhr.
});
//далее view
var BookForm = function ($container) {
this.onClickSubmit = function (cb) {
$($container).on('click', '.js-submit', function () {
cb(formData) //тут можно прокинуть все поля формы
});
};
};
//непосредственно инит приложения
$(function () {
bookService.on('add', function () {
//Вызвать какое-либо изменения интерфейса
//Не обязательно BookForm, а любого другого.
});
var bookForm = new BookForm(/**/);
bookForm.onClickSubmit(function (formData) {
bookService.add(formData);
})
});
Как-то так. Основная идея, что представление и бизнес логика очень слабо связаны. Другой вопрос в том, удобно ли так описывать интерфейсы.
Почему всегда сравнивают jquery лапшу (без отделения бизнес логики от представления) и фреймворки? Можно так же элегантно писать использую jquery. Просто нужно вынести data за описание интерфейса. Создать какой-нибудь объект, который будет отвечать за бизнес логику и подписать на изменения его данных. Тут идея в другом, jquery это императивный подход описания интерфейса, а все фреймворки в основном используют декларативный подход
У меня netbeans тормозит при скроллинге больших файлов, а phpStorm — нет. Искал, что дела в оперативке, мол Netbeans по-минимому ее есть, но при изменении ничего не изменилось
Ваша проблема решается вынесением общего кода в пакеты и обязательного соблюдения семантического версионирования
Это не какой-то сверх человек вроде сис админа, который еще и в коде понимает. Это набор практик для интеграции разработки и эксплуатации, что бы уменьшить проблемы в сопровождении релизов до стабильной стадии. Т.е разработчик, когда пишет код должен задумываться как этот код будет работать в бою и как его эксплуатировать.
Изначально переезд на монгу обуславливался очень простым горизонтальным масштабированием (репликация, auto failover, шардирование), причем по сравнению с pg/mysql прям из коробки. И это все настраивается «по щелчку пальцев»
А с каких пор mongoDB стала key-value хранилищем?
===
REST — это архитектурный подход предполагающий клиент-серверное взаимодействие, БЕЗ хранения промежуточного состояния. Нет состояния, нет проблем, есть куча фишек вроде кеширования и слоистости. Это не про ресурсы /user:id user/:id/comment/:id, не про GET-PUT-DELETE… как думают многие и откуда растёт миф.
По поводу множества запросов — тоже полнейший бред. REST никак не стандартизирует это. Вы вполне можете создать endpoint /getFilm который вернет фильм с жанрами, актерами и т.д.
И да, в таком виде «GraphQL — сам подмножество REST».
Как-то так. Основная идея, что представление и бизнес логика очень слабо связаны. Другой вопрос в том, удобно ли так описывать интерфейсы.