TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Polylith

104 点作者 0x63_Problems10 个月前

9 条评论

scubbo10 个月前
&gt; Creating a library also harms the development experience, because changes to the code no longer take effect immediately, as we need to build a library every time we make a change.[0]<p>I see this criticism of libraries from monolith fans a lot, and it confuses me. That would be true anyway - you cannot use code until you&#x27;ve built it (unless it&#x27;s in a language which is interpreted&#x2F;unbuilt&#x2F;uncompiled etc.). This would be true if the code lived in a separate repo or in the same monorepo.<p>I suspect what they really mean is &quot;you can&#x27;t consume a new version of a library until that new version has been built _and pushed to a package registry_ from which it can then be referenced&quot;, which is just false in any language I have any familiarity with - Yarn Workspaces[1] allows the &quot;live&quot; use of Typescript libraries in a local development environment, Python has plenty of solutions[2], even the minimalist GoLang has Workspaces[3]. What am I missing? Is there some language which lacks this Workspaces support for &quot;depending on local versions of dependencies&quot; that is driving all this monolith-fever?<p>[0] <a href="https:&#x2F;&#x2F;polylith.gitbook.io&#x2F;polylith&#x2F;introduction&#x2F;sharing-code#creating-a-library" rel="nofollow">https:&#x2F;&#x2F;polylith.gitbook.io&#x2F;polylith&#x2F;introduction&#x2F;sharing-co...</a> [1] <a href="https:&#x2F;&#x2F;yarnpkg.com&#x2F;features&#x2F;workspaces" rel="nofollow">https:&#x2F;&#x2F;yarnpkg.com&#x2F;features&#x2F;workspaces</a> [2] <a href="https:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;1112618&#x2F;import-python-package-from-local-directory-into-interpreter" rel="nofollow">https:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;1112618&#x2F;import-python-pa...</a> [3] <a href="https:&#x2F;&#x2F;go.dev&#x2F;doc&#x2F;tutorial&#x2F;workspaces" rel="nofollow">https:&#x2F;&#x2F;go.dev&#x2F;doc&#x2F;tutorial&#x2F;workspaces</a>
评论 #41107798 未加载
评论 #41133246 未加载
stavros10 个月前
We decided to move from (micro)services to a Django monolith, so we consolidated our services there. We added pre-commit hooks so that nobody could call the internals of each app, only a strongly-typed interface that each app exposes (in a file called api.py).<p>This way, if any one service changes its API, the developer can just see what breaks and change all dependents. API changes are atomic, so we don&#x27;t need any API migrations or versioning, and it&#x27;s much, much easier to document API functions that are strongly typed with the appropriate types than HTTP calls.<p>The tooling is also great, to deploy a new application you just run the Django `startapp` command and that&#x27;s it. You get authentication, background processes, events, linters, etc for free. It&#x27;s very convenient, you don&#x27;t even need to talk to infra.<p>So far so good.
dang10 个月前
Related:<p><i>Understanding Polylith through the lens of Hexagonal architecture</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=38109928">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=38109928</a> - Nov 2023 (2 comments)<p><i>Polylith is a functional software architecture at the system scale</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=30697724">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=30697724</a> - March 2022 (82 comments)<p><i>Show HN: Polylith – the last architecture you will ever need?</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=25253731">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=25253731</a> - Nov 2020 (10 comments)<p><i>Show HN: Polylith – A software architecture based on Lego-like blocks</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=18123996">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=18123996</a> - Oct 2018 (5 comments)
crabmusket10 个月前
Fun opening a project page to immediately step on a LEGO brick analogy! This is a pet peeve of mine to the degree I had to write about it a little while ago: <a href="https:&#x2F;&#x2F;listed.to&#x2F;@crabmusket&#x2F;30495&#x2F;lego-blocks-are-never-a-good-analogy" rel="nofollow">https:&#x2F;&#x2F;listed.to&#x2F;@crabmusket&#x2F;30495&#x2F;lego-blocks-are-never-a-...</a><p>As for Polylith itself, it seems to have some fairly sensible non-controversial ideas like building atop a foundation of pure functions, building up shared libraries, separating code by component instead of layer, etc.
barryhennessy10 个月前
I&#x27;ve seen polylith over the years and it&#x27;s always piqued my interest.<p>I&#x27;m curious as to what has been built (by yourselves or others) in the 4 (?) years since its release. Have the experiences held up to the initial goals and designs?
skybrian10 个月前
I found it difficult to understand what it actually is by looking around the docs and blog posts. The high-level software philosophy is only giving me a vague idea by making analogies to other things like Lego bricks. There’s a lot of vocabulary but the definitions are vague.<p>It seems to be a way to arrange your source code in a monorepo? Is there a core API? Are there servers?
评论 #41133103 未加载
languagehacker10 个月前
Something about the tone of this book gives me the &quot;time cube&quot; vibe.<p>Nobody &quot;just&quot; refactors their monolithic code into a new architecture.<p>Any sufficiently advanced organization with a microservices architecture has a platform team helping to standardize applications and build out shared tooling that&#x27;s already being used across multiple services.<p>It seems like there&#x27;s plenty of room for an architecture like this, but that maybe it&#x27;s closer to what already exists in practice at the places where it will work, and doesn&#x27;t exist at organizations where it won&#x27;t work for good reason.
webel010 个月前
I&#x27;ve been mostly pleased with our use of python-polylith [1] with poetry in a production application. We output a webapp, python sdk, and CLI as separate &quot;projects.&quot;<p>It doesn&#x27;t _really_ solve python dependency&#x2F;import issues. Instead, it helps to you keep your project in discrete chunks and well-organized. It also makes it easy to package up the separate projects as artifacts.<p>I&#x27;ve run into some issues with versioning separate projects but I suspect that is a matter of bandwidth rather than an actual, insoluble issue.<p>I&#x27;d use it again at a startup or on project where you need to ship a bunch of artifacts but don&#x27;t have a lot of bandwidth.<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;DavidVujic&#x2F;python-polylith">https:&#x2F;&#x2F;github.com&#x2F;DavidVujic&#x2F;python-polylith</a>
bsima10 个月前
This just seems like a monorepo with extra steps
评论 #41125710 未加载