Сидредин Агаширинов

Я расскажу Вам про личный опыт, без претензий на истину в последней инстанции...

Для чего идеальна MongoDb? Примеры приложений, где монга будет лучше mysql?

Для человека который привык работать с реляционными БД, смириться с логикой и вообще с подобными БД - довольно сложно. Для тех, кто работает с реляционными БД профессионально - сделать это ещё сложнее...

Если сравнивать с реляционными БД и с оглядкой на конкретно MySQL - монга идеально вписывается там, где структура данных заранее неизвестна. Тут я хотел привести пример, но не смог придумать ни одного дельного примера, после того как начал плотно работать с PostgreSQL... Давайте попробую из практики. Мы один раз применяли монгу в проекте где есть десятки и сотни тысяч товарных позиций и у каждой из них свой уникальный набор различных свойств. На основе уже имеющихся свойств, "соседних" товаров, контентщику предлагался наиболее вероятный набор параметров, которые нужно заполнить, но в любой момент он мог удалить или добавить любое поле и/или множество значений одного из них, например, "Цвет: черный, серый, фиолетовый". Всё это дело попадало под разные динамические фильтры и далее по цепочке... В то время, насколько я помню ещё не было поддержки JSONB-формата у PostgreSQL, по этому мы остановились на MongoDB. Ну и конечно же, желание "воткнуть ультра новую и модную БД в проект" сыграло свою роль...

Что в монге определённо не нравится (и это не моя "идея", об этом пишут даже в учебниках под монге) - это тотальная денормализация данных. Которая в некоторых случаях может сыграть злую шутку. Например, все комментарии "поста" обычно хранятся прямо в самой сущности поста. Это очень удобно и довольно быстро работает, но... иногда это приводит к полному коллапсу. Особенно, когда у Вас перекрестная ссылочность.

Безусловно, не редко можно встретить проекты в которых даже в реляционных БД не прописаны, например, внешние ключи и контроля целостности данных как такового нет, но обычно это происходит по следующим причинам:
1. Очень низкая квалификация администратора БД проекта
2. В попытке выжать из базы больше производительности, не найдя других методов оптимизации
3. Данных настолько много, что БД/ключи - начинают "сыпаться", не редко это связано с п.1

Так же, последние тесты показывают, что PostgreSQL почти не уступает MongoDB даже в её родной среде (на уровне данных в формате JSON). А в некоторых аспектах даже превосходит её... Подробности Вы можете увидеть на некоторых конференциях по Postgres (да, на конференциях по MongoDB, Вы вряд ли увидите, как кто-то будет рассказывать, что [их любимая] монга "хуже" некоторых других движков...). Кстати, поддержку формата JSON стандартизировали (наконец-то) на уровне SQL-стандарта (если я не ошибаюсь) и в самом ближайшем будущем, думаю стоит ожидать полноценную поддержку оного в SQL-базах, в т.ч. поддержку в бинарном виде с возможностью индексации данных (кстати, некоторые SQL-базы уже такое умеют).

Моё понимание, ответа на вопрос, "когда действительно стоит использовать MogoDB?" звучит примерно так: Исключительно в тех случаях, когда Вы понимаете, что она станет действительно хорошим решением для поставленной задачи и сейчас и в будущем. В моей практике, таких проектов можно было бы насчитать ничтожно мало, а точнее около нуля, особенно с учётом развития некоторых современных SQL-БД и вообще направления "JSON в SQL" в целом. Но, безусловно такие проекты могут быть и есть (в данном случае, не у меня). Но, тут стоит обратить внимание на крайне важный факт - когда всплывает такой проект, что бы адекватно оценить наиболее оптимальную БД под него - нужно знать как минимум пару-тройку SQL-БД, со всеми их особенностями, достоинствами и недостатками... причем не просто "знать", а хорошо знать, "изнутри". А так же знать все характерные черты монги, а так же её особенности, достоинства и т.д. То есть, если Вы задаётесь вопросом, "а хорошо ли впишется монга в проект N?" и не можете найти на него однозначного ответа, вероятнее всего, что в долгосрочной перспективе, в "проект N" она впишется плохо.

P.S. В заключение, хочу ещё раз напомнить, что "JSON в SQL" - активно развивается... Со всеми вытекающими.

В Vue приложении используем препроцессор (scss). Кроме того используем внешние пакеты для вертикального ритма и сетки.

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

Вариант импортировать scss-файл с определениями в каждом компоненте сразу откинули, ибо люди мы ленивые.

Что делаем:
Подключаем в точке входа (main.js) основной стилевой файл:

import '@/styles/main.scss';
import Vue from 'vue';
//...

В нем подключаем всякое-разное-глобальное-базовое:

@import "base/normalize";
@import "base/init";
@import "base/typography";
@import "base/code";
@import "base/links";
@import "base/tables";
@import "base/buttons";
@import "base/control-group";
@import "base/general-form";
@import "parts/transitions";
...

Далаем два файла: env-development.scss и env-production.scss

$NODE_ENV: development;
@import "cfg-vars";

$NODE_ENV: production;
@import "cfg-vars";

Переменная $NODE_ENV нам нужно. чтобы управлять стилями в зависимости от окружения.
Дальше в cfg-vars.scss подключаем/пишем все необходимые глобальные конфиги

$DEV_MODE: $NODE_ENV == development;
$MAX_INT32: 2147483647;

@import "cfg-vrhythm";
@import "cfg-grid";
@import "../../../node_modules/vrhythm/source/vrhythm";
@import "../../../node_modules/bs-grid-system/source/scss/bs-grid";
@import "../mixins";
@import "cfg-z-indexes";

$wt-family-base: "Open Sans", sans-serif;
$wt-family-head: "Roboto Slab", serif;
$font-family-monospace:  "Fira Code", Menlo, Monaco, Consolas, "Courier New", monospace;

//==
//== Color palette
//== ======================================= ==//

$palette-light-blue: #3c8dbc; // Primary
$palette-red       : #dd4b39; // Danger
$palette-green     : #00a65a; // Success
$palette-aqua      : #00c0ef; // Info
$palette-yellow    : #f39c12; // Warning

...

Почти всё готово. Осталось только автоматически подключить эти конфиги к сборке.
Идём в vue.config.js и добавляем секцию css:

const NODE_ENV = process.env.NODE_ENV === 'development'
    ? 'development'
    : 'production';
//...
module.exports = {
    //...
    css: {
        extract: NODE_ENV === 'production',
        loaderOptions: {
            sass: {
                data: `@import "@/styles/config/env-${NODE_ENV}.scss";`,
            },
        },
    },
};

Теперь мы спокойно пишем стили компонентов на scss прямо vue-файлах, и оставляем возможность какие-то стили писать в отдельных файлах.

Enjoy!

Добрый день.

или стоит выучить ООП и только потом посмотреть данный плейлист?

Да, ознакомьтесь сначала с документацией по php.
Затем можете приступить к ознакомлению с основами ООП. Так же перечитайте всё, что идёт в дополнении к курсу, ссылку найдёте внизу страницы.
Потом посмотрите вот эти видео.
Изучите парочку frameworko-в.
После всего этого можете приступать к написанию чего-либо.

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

Я делаю систему контроля яркости.
Я хочу настраивать яркость всего (гирлянды, люстры, фонарика, экрана телефона).
В коде выглядит примерно так

class BrightControl
   public void setDefaultBright(Object obj){
         obj.setBright(10);
   }
}

Метод setDefaultBright принимает любой объект. Ведь мне всё равно яркость чего настраивать.
Мой код используют другие разработчики, я не могу контролировать их.
Как мне убедиться, что у объекта, который мне пришел в качестве аргумента, есть метод setBright?
Я пишу интерфейс, и говорю, что метод setDefaultBright принимает только объекты, которые реализуют этот интерфейс.

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

Основной посыл использования RESTful API - применение основной идеи Паутины для взаимодействия автоматических агентов (приложений), а не только людей.
Основная идея Паутины - построение распределенной информационной системы путем публикации неких абстрактных ресурсов, выдачи им идентификаторов (в сегодняшнем вебе - иерархических), определения ряда простых и широко известных операций над ними, не зависящих от содержимого ресурса (те самые GET, POST, PUT и т.д.), и связывания этих ресурсов ссылками (это называется гипермедиа, и в частности, гипертекст, если речь идет о текстовой информации).
Как люди с появления Веба публикуют информацию в нем для потребления другими людьми, так и RESTful веб-сервисы публикуют иерархически структурированные ресурсы для потребления клиентами. Разница только в представлении - для людей это plaintext/HTML, для автоматических агентов - это JSON/XML/прочие форматы, которые удобно обрабатывать.
Таким образом, если вы хотите какую-то информацию опубликовать как RESTful API, вам необходимо представить ее как набор ресурсов, а все операции над этой информацией выразить через набор предопределенных операций. Фишка в том, что во многих задачах этих предпопределенных операций вполне достаточно, главное правильно определить ресурсы.
Важно понимать, что "ресурс" это обычно некоторая сущность, "существительное". Как правильно заметил Антон Жуков , ресурс /getItems хоть и может существовать в принципе, говорит о неудачно спроектированном API (действие представлено как ресурс).

Есть и другие подходы к архитектуре распределенных приложений, например архитектуры, основанные на RPC (удаленный вызов процедур). Информация в таких архитектурах также представлена в виде некоторого набора сущностей, однако операции над ними определяются конкретной задачей, и для каждой сущности будет свой набор. Это больше соотвествует классическому ООП-подходу. Таким образом, RESTful следует подходу много сущностей (ресурсов) - мало операций (и эти операции известны заранее), а RPC - немного сущностей, но много операций над ними.

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

Сама архитектура REST не привязана к конкретным технологиям и протоколам, но в реалиях современного Веб, построение RESTful API почти всегда подразумевает использование HTTP и каких-либо распространенных форматов представления ресурсов, например JSON, или, менее популярного сегодня, XML.

Смысл использования REST в том, что принципы, хорошо показавшие себя в "человеческом" веб и позволившие построить самую большую распределенную ИС, применяют и для "веба машин".

Ответ длинноват, но как короче объяснить, чтобы не исказить понимание, не представляю. Если что непонятно - спрашивайте.