All streams
Search
Write a publication
Pull to refresh
6
0
Леви Михаил @mixir

Full Stack Developer

Send message

Высокий порог входа k8s, отладка операторов, отладка сети внутри, отладка крэша подов. Ох, это должно было быть приключение на 20 минут, а не на 2 недели...

Шардинг БД сервиса должен быть сделан отдельно, не надо каждому инстасу делать свою отдельную БД, бд одна в рамках сервиса.

Для большого проекта лучше использовать DI чем глобальные переменные.

Крайная версия стандарта 4.01 датируется 2019 годом. Там так же есть выборка возвращаемых полей ($select) и можно строить запросы с получением данных из связанных источников в едином запросе ($expand). В этом ключе это достаточно сильный конкурент GraphQL.

Мы изучили рынок, посмотрели, какие технологии и подходы используются: REST, SOAP, RPC, Swagger (Open APi), GraphQL. Лучше остальных всем нашим требованиям отвечал GraphQL. Технологию разработали в Facebook в 2012 году, а в 2015-м выложили в открытый доступ.

Рассматривали ли вы OData ? Если да, то почему не выбрали этот стандарт?

Приватные методы и свойства всегда делались в es5 через замыкания, так что утверждение насчёт того что можно сделать их исключительно с weakmap не верно. Weakmap использовали только тогда когда можно было объявлять классы через директиву class но ещё не была введена поддержка приватных полей через #.

Если хранить как переменную внутри замыкания то тогда юзер потеряет доступ когда воркер помрет. Подводные камни Service Workers
Для валидации самого токена обращаться к бд не нужно, достаточно проверить его подпись и экспирацию.
Дополнительное обращение к БД имеет место быть если нужно проверить что токен отозван, это не всегда нужно.
Самый простой пример: несколько сервисов, на страницах которых блок «профиль» в шапке сайта формируется без обращения к БД. Или пример микросервисов где каждый сервис будет знать ID, уровни доступа и т.п. данные пользователя без обращения к БД.

Где Вы персистентно будете хранить токены в воркере?
Согласен, Ваши замечания по поводу оценок обоснованы. Тут субъективная оценка с большим временем ротации. Чем меньше времени до рефреша токена тем меньше шансов его использовать повторно (навредить, исследовать систему и тд.), но больше нагрузки на бэк.
Статья не о том что JWT это хорошо или плохо, а о том где и как хранить токены.
Конечно, микросервисы являються тем местом где лучше всего их применять, с другой стороны можно рассмотреть кейс, к примеру, сайта где API для SPA и для мобильного приложения общий.
Основная причина — поддержка инкрементальной сборки, и как следствие ускорение пересборки проектов.
Это все в планах, пока есть скудное упоминание в репо Ангуляра:
github.com/angular/angular/blob/master/docs/BAZEL.md
Правила сборки для TS:
github.com/bazelbuild/rules_typescript

Не увидел в оглавлении ничего про Angular Universal, для сайтостроительства с упором на seo это важно. Так же, SystemJS уже не используется, т.к. мигрировали на вебпак, но это не надолго, и в будующем от WebPack откажутся в пользу Bazel.

Про парадокс Парадокс Эйнштейна — Подольского — Розена не совсем понятно описано, так можно передавать данные или нет? Скажем если взять (в теории) два квантово запутанных электрона, разнести их на тысячи КМ и считывать их состояния с определенной частотой?

Information

Rating
Does not participate
Registered
Activity