Сергей Протько

Я бы всё это дело обернул в человекопонятный DSL: $user->likes($entity);.
А уже внутри метода likes() создаётся объект Like, в который передаётся лайкнутая сущность (ну и пользователь, разумеется) и там внутри уже разруливается конкретное поле, которое нужно заполнить. Инкапсуляция, полиморфизм, все дела.

Те же яйца, только сбоку: $entity->likedBy($user).

Если в качестве источника действия установить пользователя, то можно будет написать вдобавок $user->noLongerLikes($entity), чтобы снять лайк. При другой организации DSL получится страшненький.

P.S. Лучше оперировать целыми объектами, а не передавать туда-сюда id. Это позволит и код кое-где упростить и тайпхинты расставить.

Postgres

умеет быть консистентной
умеет json

Некоторые можете. Например Angular. Он как bower и npm пакет поставляется. Нужно читать описание модуля.
NPM просто менеджер пакетов. Не более.

Так как документация свободно редактируется - кто-то нагадил.

upd:
Я зарегался и удалил эту ссылку. Так что в этой документации править может любой, что угодно и где угодно.

upd2:
До этого редактировал статью: https://developer.mozilla.org/ru/profiles/AlexeyFedotof
Вроде он норм переводил, судя по ревизиям, может взломали или случайно вставил.

upd3:
Ссылка появилась 1 июня в этой ревизии:
https://developer.mozilla.org/ru/docs/Web/SVG/Элем...
Автор: https://github.com/CreativeSeo33
Исходники сайта: https://github.com/SC33/skgolden
Скорее всего ссылка была дана действительно, как пример(хоть и совсем не очевидный), ибо в исходниках на главной действительно есть тег <g>

Вот правильное решение. Пользуйся Blade.

@unless (Auth::check())
You are not signed in.
@endunless

Это из документации:
https://laravel.com/docs/master/blade

Откройте исходники ноды и посмотрите, там 2 пробела.

1) Нельзя создать инстанс абстрактного класса.
2) Методы объявленные как "abstract" - обязательны к реализации. Что дает уверенность в том, что любой наследник будет реализовывать эти методы.
3) Открыв файл с абстрактным классом, я сразу вижу методы которые у него есть, и которые мне необходимо реализовать. В вашем же примере я не знаю какие методы относятся конкретно к ChildClass, а какие к ClassName.

Все эти интерфейсы, абстрактные классы и т.д и т.п нужно тогда, когда над проектом работает несколько (много) человек, и проект чуть больше чем "свой мегакрутой бложик".

Это нужно для гарантии того, что в наследуемых классах будет реализован метод с тем же названием и похожим функционалом. Например, у классов Треугольник и Круг должен быть реализован абстрактный метод get_area, который считает площадь. Иначе можно писать в одном классе area, в другом get_area, что вызывает путаницу и проблемы с поддержкой кода. Имхо, думаю это не вся суть:)