Вообще в теории запрос из браузера в БД возможнен) Есть например PostgREST, надстройка над БД, которая предоставляет круд интерфейс к БД, так что думаю можно и из браузера вызывать. Но кому и зачем это надо, не ясно. Ну и да, это http прослойка, считай тот же самый бек.
ivan58, используются все, только для разного назначения и в разное время. Такого, что во время выполнения какой-то кусок программы лежит в eeprom, какой-то в sram - НЕТ.
я подозреваю у него нет никаких констрейнтов на уникальность, так что пользователь так и будет создаваться и ошибки никакой не будет чего он как раз хочет избежать
Ипатьев, типизация в вашем случае строже не получается, просто вы неявно сделали эдакий NullObject. Типизация нам говорит о том, чего ожидать от обьявленного типа. В данном случае получается что-то типа Optional, т.е. обьекта может не быть и мы явно указали чего ожидать. Как потом проверять, это действительно юзер, или фейк обьект? Всё таки ?UserObject проще и правильней будет. Если я запрашиваю юзера по id=1 допустим, и мне возвращается нул, то я явно понимаю и обрабатываю кейс если такого юзера нет. В вашем случае я не понимаю как обрабатывать тот же самый кейс.
Господи прекрати распространять легенду что новичков не берут на удаленку) Берут. Не знаю на сколько часто, не мерял, но берут. У меня на работе полностью распределенная команда, в ней как минимум два джуна на фронте и один начинающий админ, и все трое удаленно работают.
AUser0, не буду говорить, что понимаю как это работает на уровне ядра, но разве не приложение создает соединение в т.ч. создавая сокет? Почему оно неизвестно на момент TCP hanshake? И что значит "выбран"?
nowm, тогда странно, обычно это должно работать и процесс должен показываться. Я не эксперт в этом, но где-то читал, что руткиты могут скрывать процессы. Возможно стоит посмотреть в эту сторону.
Отсутствующий процесс может означать, что недостаточно прав для просмотра, что это за процесс. Если под судо запустить нетстат, то вполне вероятно процесс станет известен.
Обычно под сервисом имеют ввиду сервисный слой. Т.е. некий класс который реализует бизнес логику. ООП здесь никаким уже не пахнет, но это то дерьмо к которому пришли разработчики спустя столько лет :)
Мартин эти сервисы например называет UseCase
Sergey Myasoedov, распределенные транзакции они на то и распределенные, что выполняются не в рамках инстанса (физического) одной базы данных. По этой причине одна база данных не может гарантировать такие транзакции. Почитайте на эту тему "Designing Data Intensive Applications", главу про согласованность и консенсус. Так же полезно на эту тему узнать что такое паттерн Saga
tcccccc, Vladimir Onokhov, эти советы будут актуальны долгое время. Единственное что хотелось бы поправить - не UML а ERD диаграммы для БД нужно изучать + crow foot notation
