I never thought about VSCode extension for this thanks! Will think about it.
For the generation of swagger endpoint definition based on a function signature — it's not that easy. I wanted to to this in the beginning but then ended up with the existing solution. So now instead of getting SwaggerEndpointDefinition from signature (which should be edited to allow some additional information like shape of the body object, parameters in URL or query, etc etc etc) this definition is done manually in JSON and then your method signature looks almost like in GraphQL: list of arguments coming from any source (body, url, query) and a context (for auth flow) and a request (not implemented yet, will be implemented in future as I need it now for my projects)
Tree-based API navigator — cool idea as well. Will think about VSCode extension fo this, thanks :)
В нашей реализации нет, мы просто выбирали узлы случайно. Но в принципе нет ничего сложного объеденить их по стране, общей компании или же даже по одному банкомату, в котором они снимают деньги одновременно раз в месяц с разницей в 2 минуты :)
Почему? Эта информация теоретически может быть использована алгоритмами. В нашем же случае это просто почти полный список того, что библиотека Mimesis могла генерировать :)
Ух ты, интересно, чего пишет про приложение? Почему не получилось? Я проверю в настройках, но оно вроде как в публичной бете для всех стран… Но я перепроверю ближе к ночи и отпишусь
Выбор технологий — сугубо индивидульными предпочтениями и желанием научиться играть в правильный Devops и микросервисы )
Спасибо!
Делаю в свободное время, но сейчас момент когда он съедает слишком много ресурсов и времени, поэтому планирую начать им заниматься серьезно и поноценно. Для этого и рассказываю о нем здесь — узнать, интересен ли он, может быть найти единомышленников и желающих работать со мной.
Соответственно с удовольствием расскажу и покажу больше по проекту, если у кого-либо есть такое желание. Просто пишите на nikita@quester-app.io и можем договориться о встрече / звонке
Вот это прям очень неожиданный косяк конечно с моей стороны, совсем забы об этом и не подумал заранее… Приношу свои извинения и посыпаю голову пеплом :(
Хм, а знаете, я не подумал о доступности ссылок из России… Все задеплойно на Digital Ocean в лонднском датацентра. Я не следил особо за тем что имеено блокируется из России, может ли быть это как-то связанно?
Ух ты, я работаю с автором этой статьи в одной команде :) Не ожидал увидеть здесь перевод его статьи. Расскажите мне, если не сложно — он достаточно известная личность в iOS разработке?
Я еще раз внимательно перечитал ваш пост — да, вы на самом деле используете редукс так же как и предлагает документация, только называете все терминами MVC. Не могли бы вы привести пример использования middlewares в том же ключе MVC? Просто я в вашем коде вижу чистейший флюкс (ну хорошо, да, не флюкс а редукс, но все же) просто с подогнанными названиями из MVC которые очень хорошо легли на пример из вашей статьи. И в связи с этим ощущаю некий диссонанс :)
Ну или даже вот такой вопрос — зачем писать используя Flux и называть это MVC? По сути у вас все view обращаются к одной модели через контроллеры этих вьюх посредством кидания экшнов, а модель автоматически обновляет вьюхи… эм, ну то есть у вас однонаправленное движение данных, как и нужно в Flux.
А зачем строить MVC на редуксе с реактом когда их связка создана ради Flux-архитектуры? А если нет возможности использовать Flux то зачем использовать редукс когда можно использовать что-либо более MVC с реактом?
Я думаю, что мой вопрос повлечёт за собой отдельную статью, но все же задам его. Как работают DSP и SSP? В общем виде? Как происходит оценка показа и/или перехода, хотя бы разобранный пример? Как можно сравнивать между собой разные DSP и SSP? По каким параметрам? Где в этой схеме таргетинг, сколько стоит именно он, от чего зависит и какие возможности/предложения бывают?
В общем интересно было бы прочитать ваш последний абзац, но развернуто и понятно
Спасибо огромное! Буду пробовать. А то у меня network analysis на графе в миллионы узлов — бедный Node.js считает несколько минут, пользователи наслаждаются логотипом загрузки…
По работе тоже нужно было ускорить критическую часть, тоже решил сделать это на Rust, заодно его и подучить. Но была одна маленькая деталь — функция в Rust должна была возвращать в Node.js объект, а не примитивный тип, и с этим я не справился. Велосипед в лице передачи строки и последующего JSON.parse, кроме потери любого выигрыша в производительности, не подошел т.к. возвращаемая строка была слишком длинной и все падало в момент получения нодой. Где-то прочитал, что в FFI можно передать указатель на объект, и в ноде его уже считать из памяти, но так и не разобрался с этим решением. Может у кого-нибудь была похожая задача?
For the generation of swagger endpoint definition based on a function signature — it's not that easy. I wanted to to this in the beginning but then ended up with the existing solution. So now instead of getting SwaggerEndpointDefinition from signature (which should be edited to allow some additional information like shape of the body object, parameters in URL or query, etc etc etc) this definition is done manually in JSON and then your method signature looks almost like in GraphQL: list of arguments coming from any source (body, url, query) and a context (for auth flow) and a request (not implemented yet, will be implemented in future as I need it now for my projects)
Tree-based API navigator — cool idea as well. Will think about VSCode extension fo this, thanks :)
Выбор технологий — сугубо индивидульными предпочтениями и желанием научиться играть в правильный Devops и микросервисы )
Делаю в свободное время, но сейчас момент когда он съедает слишком много ресурсов и времени, поэтому планирую начать им заниматься серьезно и поноценно. Для этого и рассказываю о нем здесь — узнать, интересен ли он, может быть найти единомышленников и желающих работать со мной.
Соответственно с удовольствием расскажу и покажу больше по проекту, если у кого-либо есть такое желание. Просто пишите на nikita@quester-app.io и можем договориться о встрече / звонке
А фильм нерв был толчком к появлению идеи :)
Постараюсь добавить, как время появится.
В общем интересно было бы прочитать ваш последний абзац, но развернуто и понятно