• Как уменьшить сложность и тяжеловесность "контроллеров" в API приложениях?

    @Akela_wolf
    Extreme Programmer
    Путь к уменьшению сложности один - декомпозиция.
    Выносить все лишнее в отдельные классы и модули.
    Скажем, стоит выносить логику валидации запросов из контроллера в отдельные классы, оставляя в контроллере только абстрактное: валидировать. логировать. передать на обработку. вернуть результат.
    Тоже самое в сервисах: выносить логику обращения к БД, обращения к внешним сервисам и т.д., оставляя только то что относится непосредственно к ответственности сервиса

    См. книгу Р. Мартин "Чистая архитектура", вот статья об этом на хабре
    Ответ написан
    2 комментария
  • Если в случае получения "expired" ресурса потребуется создать новый ресурс, то "кто" должен это сделать?

    @Drno
    Вам надо менять ссылку? или ссылка остается такая ? (для проксирования? )
    Если такая же - на сервере 2. Если меняется - на сервере 1, чтоб вписать новую ссылку в конфиг прокси сразу
    Ответ написан
    1 комментарий
  • Какие курсы по реакту можете посоветовать?

    Alexandroppolus
    @Alexandroppolus
    кодир
    Курсы - лажа: "тренеры" зарабатывают деньги на школоло (и приравненных к ним лицах), уверенных что без курсов никак.
    Рулит самообразование, но надо по порядку.

    html/css: стартануть можно отсюда, потом догоняться здесь и здесь
    JS: https://learn.javascript.ru/. Учебник без ереси.
    Ну и конечно https://developer.mozilla.org/ru/docs/Learn - там много чего есть. Это всё справочники.
    TS: https://www.typescriptlang.org/docs/. Там же есть playground.

    Разобравшись со всеми этими штуками и с тем как их применять, можно взяться за Реакт и без проблем освоить официальную документацию. Потом - стейтманагеры: redux, mobx. Потом - nextjs/gatsby. Вот примерно так.
    Ответ написан
    Комментировать
  • Какие данные должны возвращать GET-запросы к вложенным ресурсам в rest api?

    @romicohen
    Системный Архитектор
    Смотри, такие роуты

    /organizations/{organizationId}/departments/{departmentId}/employees/{employeeId}

    (обычно без слэша на конце) используют когда речь идет о древовидной иерархии.

    Т.е. когда у тебя для одной организации /organizations/{organizationId} есть один или более департаментов, и для каждого департамента /organizations/{organizationId}/departments/{departmentId} есть один и более эмплоеров.

    По идее, ты можешь получить всё дерево целиком:

    GET /departments

    даже не вопрос :) А можешь на этот же роут отдавать не дерево, а простой список айдишников организаций. Тут в зависимости от твоих целей.

    А можешь так:

    GET /departments?mode=list (список аудишников)

    GET /departments?mode=tree (всё дерево)

    вот это:

    GET /organizations/{organizationId}/departments - подразумевает что ты отдаешь все департаменты для какой-то определенной организации ({organizationId}) - то же самое, можешь списком, можешь деревом, без разницы ))

    Всё зависит от потребностей фронта.

    Общий принцип: не отдавать больше, чем нужно :)
    Ответ написан
    1 комментарий
  • Как углубится во что то одно, а не изучать все поверхностно?

    @d-sem
    Пробовать все - нормально.
    В какой то момент, что-то да захватит. Возможно, просто еще не найдена своя ниша.

    А с концентрацией - скорее всего вопрос целеполагания. Если поставить цель сталь джуном в каком то направлении и идти к ней - то все будет ок. А пока все делается добровольно и по настроению - такие перескакивания и будут.

    Мне лично помогло не размазываться осознание того что у меня скоро закончится финансовая подушка и никто мне не поможет. А семью нужно кормить и счета платить. Знание даты когда у тебя кончатся деньги и тебе нечего будет есть - очень мотивирует стать джуном :)
    Ответ написан
    1 комментарий
  • Как назначить интерфейс с обязательными полями для контекста без дефолтного значения?

    Alexandroppolus
    @Alexandroppolus
    кодир
    На мою имху, лучше всего такой вариант:
    const Context= React.createContext(null as unknown as IContext);
    
    ...
    const { someClass } = useContext(Context);


    да, это обман тайпскрипта и ошибка переедет в рантайм, но в случае с контекстом такого не избежать, потому как TS не может проконтролировать наличие провайдера. Данный вариант сразу обнаруживает ошибку в рантайме во время дебага, после чего следует одноразовая починка - добавляется забытый провайдер.

    если компонент, использующий значение из контекста, может без него обойтись, и например, что-то осмысленное нарисовать, то можно так:
    const Context= React.createContext<IContext | null>(null);


    тогда useContext вернет IContext | null, то есть значение просто надо проверять на null и в этом случае что-то делать - например, отрендерить какое-то сообщение. Но если от значения контекста зависят другие хуки, то везде надо втыкать проверку и будет лишний говнокод.

    худший вариант - воткнуть в createContext бессмысленную заглушку, формально соответствующую интерфейсу. Это так же приведет к ошибке в рантайме (если забыли провайдер), но ошибка будет скорее всего малопонятная, в отличии от первого варианта.

    ну и разумеется, в контексте может лежать что-то простое, например, текущий язык, тогда задание дефолтного значения имеет смысл.
    Ответ написан
    Комментировать
  • Как назначить интерфейс с обязательными полями для контекста без дефолтного значения?

    @wonderingpeanut
    interface MyLittleInterface {
      age: number;
      name: string;
    }
    
    const someVar: MyLittleInterface = {}; // ой-ой! 
    const someOtherVar: MyLittleInterface = {} as MyLittleInterface; // Ура!
    Ответ написан
    1 комментарий