Hacker News Digest

Команда Bellroy автоматизировала работу с ERP-системой, где каждый запрос к API требует предварительных шагов — например, чтобы создать запись, нужен ID другой сущности, что требует дополнительных запросов.

Умный подход: вместо цепочки запросов "запроси A, затем с результатом запроси B" они используют аппликативные функторы. Эти структуры позволяют собрать все нужные запросы в один пакет (отсюда "free applicative"), отправить их разом и потом разобрать ответы, сопоставляя каждый с исходным запросом.

Так они избегают проблем "callback hell" и сохраняют код декларативным. Например, вместо ручной обработки каждого ответа они описывают граф запросов через Free Applicative, а исполнение — дело интерпретатора, который может батчить запросы и парсить ответы.

Особенно изящно это работает с "handle pattern", где каждая операция (типа "получить цену товара") представлена как handle, а реализации могут быть разными (реальная БД vs. мок для тестов). Аппликативы же позволяют комбинировать эти handles в сложные запросы, оставаясь агностичными к источнику данных.

В итоге, Bellroy получает код, где бизнес-логика описана как композиция handles, выполнение оптимизировано (батчинг, кеширование), а тесты пишутся просто — подменой handles на заглушки.

• Bellroy, известный своими кошельками и аксессуарами, использует Haskell и Nix, что вызывает удивление и вопросы о масштабе и прибыльности компании.
• Пользователи обсуждают, как компания, которая начиналась как производитель кошельков, может позволить себе такой стек технологий.
• Обсуждение также затрагивает вопрос о том, как язык программирования и инструменты разработки могут влиять на продукт и его качество.
• Участники также обсуждают, как компания, которая начиналась как производитель кошельков, может позволить себе такой стек технологий.
• В конце, участники обсуждения приходят к выводу, что, возможно, это просто "разработчики, которые ушли в бизнес кошельков", и это может быть просто пример того, как красивые вещи могут появиться из самых неожиданных мест.

First off, congrats, this is no small feat, well done.A question: in my (limited) experience, ERPs are made on the basis of integrations. I'd have thought the best priority order would be data-model first, integration second, everything else third. How do you think about this? Wh