Какая правильная архитектура для restapi на nodejs?
Потихоньку мигрирую с php на nodejs с использованием typescript.
Много читаю информации из гугла, но и хотел бы тут увидеть как выстраивается архитектура restapi.
А именно больше вопросов возникает.
1) Как создавать и подключать правильно конфиги например для подключения и работы с бд
2)Есть ли аналог что то похоже на namespace/use , autoloader.
3)Да и сама архитектура, рад был бы хорошему примеру с github/bitbucket где уже используется и подключение к бд, и разные конфиги. Да и все выстроено что бы на примере можно было это дело изучить поковырять
galliard, потому что системы типов у ТС не существует. Там есть только статический тайп-чекинг, что приводит к тому, что названия классов все равно нужно передавать отдельным аргументом в функции и конструкторы, к тому, что классы не знают о собственных дженериках внтури методов, к тому, что нельзя проверить переменную на наследование интерфейса и так далее. В целом система типов ТС не заточена под ООП, а вместо этого использует что-то другое, название чего я забыл, но суть в том, что идея - в проверке наличия конкретных методов и пропов, а ООП - лишь метод представления для удобности. С таким подходом я в корне не согласен по многим причинам, некоторые из которых:
- ужасный рефакторинг
- нужда запоминать кучу всего, вместо того, что бы это делала IDE
- причины, указанные выше
Смотрел видео по какой-то конференции, где обьясняли, в чем задумка ТС. Если интересно - могу порытся в истории, но это было давно, так что не факт, что найду.
В тоже время у ПХП вообще нету дженериков, НО типы - реальные. Можно узнать типы аргументов функции, например, спарсить и отобразить в доке, в то время как в ТС для этого потребовался бы отдельных список типов. Применение - не только это, и тут проще было б сравнить джаву и тс. ПХП так же ближе к джаве по этой причине, ежели ТС.
Более того, в ПХП по-дефолту если указан тип - переменная non-nullable. Из-за того, что IDE пока что не сообщают об этом - иногда возникают проблемы, но со временем все станет лучше, и non-nullable останется. В ТС же вообще похрену - переменная может быть чем угодно, хоть null, хоть undefined, хоть NaN. Опять же, гуглится kotlin non-nullable vs java
Да, система типов в ПХП не идеальна - но ей есть куда расти, в отличии от TS. Тот в тупике, и преимуществ реальной системы типов он не получит никогда. А вот пхп с каждым годом становится лучше, хоть это и происходит пипец как медленно.
