Да, существует одна общая БД юзеров, на основе которой выдаются OAuth2 токены. В каждом запросе к микросервису есть заголовок X-User с идентификатором пользователя, то есть микросервис всегда знает, что любой запрос к нему — прошел аутентификацию. Микросервису остается сделать авторизацию основываясь на любой своей внутренней логике. Это традиционный способ для этой архитектуры — так советуют делать книги.
Сейчас пробрасывается User ID из токена и оригинальный IP. В принципе, очень просто добавить любые другие заголовки. А как бы Вы использовали Request ID?
1) Во владении русским языком Вы уступаете даже Вите АК. Вы могли, хотя бы, авто-корректором каким-то пройтись?
2) «Это число недавно чуть уменьшилось для фреймворка в целом так как вышли 3 новых компонента, к которым пока еще и документации нет, и тесты там только в процессе, но через короткое время вновь будет 100%»
Тесты пишутся перед написанием кода, документация тут не причем.
3) «PHPixie использует ПХП как шаблонизатор, а это означает что все привычные функции например ucwords, substr, trim итд. уже доступны и новый язык учить не придется»
Не совсем уместное сравнение — Вы можете вставлять чистый PHP (не ПХП) код в шаблоны Blade.
4) «Тут у нас вновь разница парадигм. Laravel как более монолитный фреймворк предоставляет возможности байндинга к моделям, позволяя полностью пропустить код контроллера»
Это семантическая бессмыслица. Laravel позволяет вместо имени контроллера передать closure, и это не имеет никакого отношения ни к байндингу, ни к монолитной архитектуре (которой у него нет).
Сейчас есть только континенты в Earth, и они определены международным обществом :)
Не уверен, что кому-то пригодится вывести список стран макрорегиона? Если честно, даже и про континент не уверен – просто это было в исходной базе Geonames, не стал убирать.
Вы можете привести пример, когда будет полезно вывести список стран макрорегиона?
По поводу семантики в случае с 'micro' — мне самому вариант не понравился, но ничего лучше не нашел. Мысль такая, что большинству разработчиков в большинстве случаев не нужны крохотные страны с крохотным населением. Искал термин для таких стран (а ля Гибралтар) — не нашел. Но префикс «микро» иногда используется: https://en.wikipedia.org/wiki/European_microstates
Когда я начинал делать библиотеку, я даже не знал — будут ли еще какие-то куски информации переводимыми. Поэтому я последовал старому правилу «не оптимизируй заранее»
А сейчас все похоже на то, что только имена и переводятся. Вполне логично туда локаль (язык) и вставить
Хм, Вы правы — конфуз есть ;-) getLanguage() есть только у страны, но тем не менее.
На объектах городов-областей-стран этот метод для удобства, он в нем не реализован. Идея в том, чтобы можно было на любой стадии «исправить» положение. Это достаточно распространенная практика
Базы и так доступны к редактированию :) Выбран формат JSON специально, чтобы было удобно редактировать прямо через web-интерфейс GitHub:
https://github.com/MenaraSolutions/geographer/blob/master/resources/translations/country/ru.json
Долгосрочный план — что пользователи из разных стран сами будут постепенно улучшать базу
Но скорее всего базы надо вынести в отдельные репозитории, чтобы отделить возможные библиотеки на других языках от контента
2) «Это число недавно чуть уменьшилось для фреймворка в целом так как вышли 3 новых компонента, к которым пока еще и документации нет, и тесты там только в процессе, но через короткое время вновь будет 100%»
Тесты пишутся перед написанием кода, документация тут не причем.
3) «PHPixie использует ПХП как шаблонизатор, а это означает что все привычные функции например ucwords, substr, trim итд. уже доступны и новый язык учить не придется»
Не совсем уместное сравнение — Вы можете вставлять чистый PHP (не ПХП) код в шаблоны Blade.
4) «Тут у нас вновь разница парадигм. Laravel как более монолитный фреймворк предоставляет возможности байндинга к моделям, позволяя полностью пропустить код контроллера»
Это семантическая бессмыслица. Laravel позволяет вместо имени контроллера передать closure, и это не имеет никакого отношения ни к байндингу, ни к монолитной архитектуре (которой у него нет).
А вот области обязательно посмотрю. Если у них имеются коды вроде ISO/FIPS/Geonames — смогу автоматически импортнуть
Как обстоят дела с областями — есть ли все области всех стран мира? У Geonames с этим туго, сейчас приходится с Wikipedia скрейпить
Координаты у меня уже есть, они все в базе. Алгоритм простой для геоиндексации тоже придумал
Про второе неуверен — gettext, насколко я знаю, популярностью ныне не пользуется, входной порог будет выше
Цифровые добавим сегодня-завтра, спасибо за совет!
Не уверен, что кому-то пригодится вывести список стран макрорегиона? Если честно, даже и про континент не уверен – просто это было в исходной базе Geonames, не стал убирать.
Вы можете привести пример, когда будет полезно вывести список стран макрорегиона?
По поводу семантики в случае с 'micro' — мне самому вариант не понравился, но ничего лучше не нашел. Мысль такая, что большинству разработчиков в большинстве случаев не нужны крохотные страны с крохотным населением. Искал термин для таких стран (а ля Гибралтар) — не нашел. Но префикс «микро» иногда используется: https://en.wikipedia.org/wiki/European_microstates
Когда я начинал делать библиотеку, я даже не знал — будут ли еще какие-то куски информации переводимыми. Поэтому я последовал старому правилу «не оптимизируй заранее»
А сейчас все похоже на то, что только имена и переводятся. Вполне логично туда локаль (язык) и вставить
Что если надо вывести названия одной и той же страны на разных языках? :) (не только на текущем и нативном)
Я, кстати, не спорю. Я с этой целью и публиковал статью, чтобы ценные рекомендации получать :)
На объектах городов-областей-стран этот метод для удобства, он в нем не реализован. Идея в том, чтобы можно было на любой стадии «исправить» положение. Это достаточно распространенная практика
про интерфейсы Вы правы, спасибо за замечание
https://github.com/MenaraSolutions/geographer/blob/master/resources/translations/country/ru.json
Долгосрочный план — что пользователи из разных стран сами будут постепенно улучшать базу
Но скорее всего базы надо вынести в отдельные репозитории, чтобы отделить возможные библиотеки на других языках от контента