{"id":34744,"date":"2019-10-31T22:00:10","date_gmt":"2019-10-31T19:00:10","guid":{"rendered":"https:\/\/prohoster.info\/blog\/monorepozitorii-pozhalujsta-nado\/"},"modified":"2019-10-31T22:00:10","modified_gmt":"2019-10-31T19:00:10","slug":"monorepozitorii-pozhalujsta-nado","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/monorepozitorii-pozhalujsta-nado","title":{"rendered":"Monorepositories: please, it's necessary","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Monorepositories: please, it&#039;s necessary\" src=\"\/wp-content\/uploads\/2019\/05\/a973a60a06e7b336c08db26fa6d72149.JPG\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p><em>The translation of the article is prepared for the students of the course <noindex><a rel=\"nofollow\" href=\"https:\/\/otus.pw\/g5Rz\/\">DevOps Practices and Tools<\/a><\/noindex> in the educational project OTUS.<\/em><\/p>\n<p>You should choose a monorepo because the behavior it encourages in your teams is transparency and collective responsibility, especially as teams grow. In any case, you'll have to invest in tooling, but it's always better when the default behavior aligns with what you want to see in your teams. <noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p><\/p>\n<h1 id=\"pochemu-my-govorim-ob-etom\">Why are we talking about this?<\/h1>\n<p><\/p>\n<p>Matt Klein wrote an article <noindex><a rel=\"nofollow\" href=\"https:\/\/medium.com\/@mattklein123\/monorepos-please-dont-e9a279be011b\">\"Monorepos: Please don\u2019t!\"<\/a><\/noindex>\u200a (translator's note: translated on Habr <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/435306\/\">\"Monorepositories: Please don't\"<\/a><\/noindex>). I like Matt; I think he is very smart, and you should read his perspective. He initially published a poll on Twitter:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Monorepositories: please, it&#039;s necessary\" src=\"\/wp-content\/uploads\/2019\/05\/edbc65b80288045e08394821c17a77a9.JPG\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p><em>Translation:<\/em><br \/>\n<em>On this New Year's day, I will argue about how ridiculous monorepos are. 2019 started quietly. In that spirit, I propose a poll. Who are the big fans? Supporters:<\/em><br \/>\n\u2014 <em>Monorepos<\/em><br \/>\n\u2014 <em>Rust<\/em><br \/>\n\u2014 <em>Incorrect poll \/ both<\/em><\/p>\n<p><\/p>\n<p>My answer was: \"I\u2019m literally both of these people.\" Instead of discussing how Rust is a drug, let\u2019s address why I think he's wrong about monorepos. A bit about myself. I\u2019m the Chief Technology Officer at Chef Software. We have about 100 engineers, a codebase that is around 11-12 years old, and 4 main products. Some of this code is in a polyrepo (my starting point), and some in a monorepo (my current position).<\/p>\n<p><\/p>\n<p>Before I begin: every argument I present here will apply to both types of repositories. In my opinion, there are no technical reasons why you should choose one type of repository over the other. You can make any approach work. I\u2019m happy to discuss it, but I\u2019m not interested in artificial technical reasons why one is superior to the other. <\/p>\n<p><\/p>\n<p>I agree with the first part of Matt's viewpoint:<\/p>\n<p><\/p>\n<p><em>Because at a large scale, a monorepo will face the same issues that a polyrepo does but will also drive you towards a strong coupling of your code and require tremendous effort to scale your version control system.<\/em><\/p>\n<p><\/p>\n<p>You will face the same problems regardless of whether you choose a monorepo or a polyrepo. How do you release updates? What is your approach to versioning? Backward compatibility? Cross-project dependencies? What architectural styles are acceptable? How do you manage your build and testing infrastructure? The list goes on. And you will solve them all as you grow. There's no such thing as free cheese.<\/p>\n<p><\/p>\n<p>I believe Matt's argument resonates with the views held by many engineers (and managers) I respect. It stems from the perspective of an engineer working on a component or a team working on a component. You hear things like:<\/p>\n<p><\/p>\n<ul>\n<li>The codebase is bloated\u2014I don't need all this junk.<\/li>\n<li>It's harder to test because I have to sift through all this junk that I don't need.<\/li>\n<li>It's more complicated to deal with external dependencies.<\/li>\n<li>I need my own version control systems.<\/li>\n<\/ul>\n<p><\/p>\n<p>Certainly, all these points are valid. This happens in both cases\u2014in a polyrepo, I have my junk in addition to what's required for the build... I might need other junk as well. So I \u2018just\u2019 create tools that check out the entire project. Or I create a fake monorepo with submodules. We could go around this all day. But I think Matt's argument misses the primary reason I've flipped quite strongly in favor of the monorepo:<\/p>\n<p><\/p>\n<h1 id=\"on-provociruet-obschenie-i-pokazyvaet-problemy\">It fosters communication and highlights issues.<\/h1>\n<p><\/p>\n<p>When we separate repositories, we de facto create a coordination and transparency problem. This aligns with how we think about teams (especially how individual members think of them): we are responsible for a specific component. We work in relative isolation. The boundaries are fixed at my team and the component(s) we're working on.<\/p>\n<p><\/p>\n<p>As the architecture becomes more complex, one team can no longer manage it alone. Very few engineers keep the entire system in their heads. Let's say you manage a shared component A, which is used by teams B, C, and D. Team A is refactoring, improving the API, and also changing the internal implementation. As a result, the changes are backward incompatible. What advice would you give?<\/p>\n<p><\/p>\n<ul>\n<li>Find all the places where the old API is used.<\/li>\n<li>Are there places where the new API cannot be used?<\/li>\n<li>Can you fix and test other components to ensure that they don't break?<\/li>\n<li>Can those teams check your changes right now?<\/li>\n<\/ul>\n<p><\/p>\n<p>Please note that these questions do not depend on the type of repository. You will need to find teams B, C, and D. You will need to talk to them, clarify the timing, and understand their priorities. At the very least, we hope you will do that.<\/p>\n<p><\/p>\n<p>In reality, no one wants to deal with this. It's much less exciting than just fixing the darn API. It's all very human and messy. In a polyrepo, you can simply make changes, submit them for review to those working on that component (likely not B, C, or D), and move on. Teams B, C, and D can just stay on their current version for now. They will upgrade when they recognize your brilliance!<\/p>\n<p><\/p>\n<p>In a monorepo, the responsibility shifts by default. Team A changes its component and, if they're not careful, immediately breaks B, C, and D. This leads to B, C, and D showing up at A's door, wondering why Team A broke the build. This teaches A that they cannot skip my list above. They need to talk about what they are going to do. Can B, C, and D move? What if B and C can, but D was tightly coupled to the side effects of the old algorithm's behavior?<\/p>\n<p><\/p>\n<p>Then we need to talk about how we will get out of this situation:<\/p>\n<p><\/p>\n<ol>\n<li>Support for multiple internal APIs, while marking the old algorithm as deprecated until D can stop using it.<\/li>\n<li>Support for multiple release versions, one with the old interface and one with the new.<\/li>\n<li>Delay the release of changes to A until B, C, and D can adopt it simultaneously.<\/li>\n<\/ol>\n<p><\/p>\n<p>Let's say we selected 1, several APIs. In this case, we have two pieces of code. The old and the new. Quite convenient in some situations. We revert the old code back, mark it as deprecated, and coordinate its removal schedule with Team D. Essentially identical for a poly and a monorepository.<\/p>\n<p><\/p>\n<p>For releasing multiple versions, we need a branch. Now we have two components \u2014 A1 and A2. Teams B and C use A2, while D uses A1. We need each component to be ready for release because before D can move forward, there may be security updates and fixes for other bugs required. In a poly-repository, we can hide this in a long-lived branch that feels comfortable. In a monorepository, we force the code into a new module. Team D will still have to make changes to the 'old' component. Everyone can see the cost we are paying here \u2014 we now have twice the code, and any bug fixes applied to A1 and A2 must be applied to both. With the branching approach in a poly-repository, this is hidden by cherry-pick. We perceive the cost as lower because there is no duplication. From a practical standpoint, the cost is the same: you will build, release, and maintain two mostly identical codebases until you can remove one of them. The difference is that in a monorepository, this pain is direct and in plain sight. <strong>This is even worse, and that's a good thing.<\/strong><\/p>\n<p><\/p>\n<p>Finally, we have reached the third point: the release delay. It is possible that the changes made by Team A will improve the lives of Team A. Important, but not urgent. Can we simply delay? In the monorepo, we are pushing this towards artifact stabilization. Of course, we are discussing this with Team D. Just stick with the old version until you catch up! This sets the stage for a game of chicken. Team A continues working on its component, ignoring the fact that Team D is using an increasingly outdated version (that's Team D's problem, they are foolish). Meanwhile, Team D is speaking poorly of Team A's careless attitude towards code stability, if they even mention it at all. Months go by. Finally, Team D decides to look into the possibility of an update, but the changes in A have only increased. Team A barely remembers when and how they broke D. The update is more painful and will take longer. Which sends it further down the priority stack. Until the day we face a security issue in A, prompting us to create a branch. Team A has to go back in time, find the moment when D was stable, fix the problem there, and prepare it for release. <strong>This is a de facto choice made by people, and it is certainly the worst one.<\/strong> It seems good for both Team A and Team D, as long as we can ignore each other.<\/p>\n<p><\/p>\n<p>In a monorepo, the third option is really not feasible. You are forced to handle the situation in one of two ways. You need to see the costs of having two release branches. Learn to protect yourself from updates that break backward compatibility. But most importantly: <em>you cannot avoid the difficult conversation.<\/em><\/p>\n<p><\/p>\n<p>In my experience, when teams get larger, it becomes impossible to keep the whole system in mind, and that\u2019s the most critical part. You must enhance the visibility of disagreements within the system. You need to actively work to get teams to take their eyes off their components and look at the work of other teams and consumers.<\/p>\n<p><\/p>\n<p>Yes, you can create tools that attempt to solve the polyrepo problem. However, my experience with continuous delivery and automation in large enterprises tells me this: the default behavior without additional tools is what you would expect to see. <strong>The default behavior of a polyrepo is isolation; that's the whole point. The default behavior of a monorepo is shared responsibility and transparency; that's the whole point.<\/strong> In both cases, I am going to create a tool that smooths out the rough edges. As a leader, I will choose a monorepo every time because tools should reinforce the culture I want, and that culture stems from tiny decisions and the daily work of the team.<\/p>\n<p class=\"for_users_only_msg\">Only registered users can participate in the survey. <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/auth\/login\/\">Please log in<\/a><\/noindex>, please.<\/p>\n<h2 class=\"default-block__polling-title\">Who are the bigger fanatics? Advocates:<\/h2>\n<ul class=\"content-list content-list_polling\">\n<li class=\"content-list__item content-list__item_polling\">\n<p>                    Monorepos<\/p>\n<\/li>\n<li class=\"content-list__item content-list__item_polling\">\n<p>                    Rust<\/p>\n<\/li>\n<li class=\"content-list__item content-list__item_polling\">\n<p>                    Incorrect poll \/ both<\/p>\n<\/li>\n<\/ul>\n<p>    33 users voted. 13 users abstained.<br \/>\n<br \/>Source: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/otus\/blog\/453958\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0435\u0440\u0435\u0432\u043e\u0434 \u0441\u0442\u0430\u0442\u044c\u0438 \u043f\u043e\u0434\u0433\u043e\u0442\u043e\u0432\u043b\u0435\u043d \u0434\u043b\u044f \u0441\u0442\u0443\u0434\u0435\u043d\u0442\u043e\u0432 \u043a\u0443\u0440\u0441\u0430 \u00abDevOps \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0438 \u0438 \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u044b\u00bb \u0432 \u043e\u0431\u0440\u0430\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u044c\u043d\u043e\u043c \u043f\u0440\u043e\u0435\u043a\u0442\u0435 OTUS. \u0412\u044b \u0434\u043e\u043b\u0436\u043d\u044b \u0432\u044b\u0431\u0440\u0430\u0442\u044c \u043c\u043e\u043d\u043e\u0440\u0435\u043f\u043e\u0437\u0438\u0442\u043e\u0440\u0438\u0439, \u043f\u043e\u0442\u043e\u043c\u0443 \u0447\u0442\u043e \u043f\u043e\u0432\u0435\u0434\u0435\u043d\u0438\u0435, \u043a\u043e\u0442\u043e\u0440\u043e\u043c\u0443 \u043e\u043d \u0441\u043f\u043e\u0441\u043e\u0431\u0441\u0442\u0432\u0443\u0435\u0442 \u0432 \u0432\u0430\u0448\u0438\u0445 \u043a\u043e\u043c\u0430\u043d\u0434\u0430\u0445 \u2014 \u044d\u0442\u043e \u043f\u0440\u043e\u0437\u0440\u0430\u0447\u043d\u043e\u0441\u0442\u044c \u0438 \u043a\u043e\u043b\u043b\u0435\u043a\u0442\u0438\u0432\u043d\u0430\u044f \u043e\u0442\u0432\u0435\u0442\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0441\u0442\u044c, \u043e\u0441\u043e\u0431\u0435\u043d\u043d\u043e \u043f\u0440\u0438 \u0440\u043e\u0441\u0442\u0435 \u043a\u043e\u043c\u0430\u043d\u0434. \u0412 \u043b\u044e\u0431\u043e\u043c \u0441\u043b\u0443\u0447\u0430\u0435 \u0432\u0430\u043c \u043f\u0440\u0438\u0434\u0451\u0442\u0441\u044f \u0432\u043a\u043b\u0430\u0434\u044b\u0432\u0430\u0442\u044c\u0441\u044f \u0432 \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u0430\u0440\u0438\u0439, \u043d\u043e \u0432\u0441\u0435\u0433\u0434\u0430 \u043b\u0443\u0447\u0448\u0435, \u043a\u043e\u0433\u0434\u0430 \u043f\u043e\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u043f\u043e \u0443\u043c\u043e\u043b\u0447\u0430\u043d\u0438\u044e \u2014 \u044d\u0442\u043e \u043f\u043e\u0432\u0435\u0434\u0435\u043d\u0438\u0435, [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":26181,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-34744","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0435\u0440\u0435\u0432\u043e\u0434 \u0441\u0442\u0430\u0442\u044c\u0438 \u043f\u043e\u0434\u0433\u043e\u0442\u043e\u0432\u043b\u0435\u043d \u0434\u043b\u044f \u0441\u0442\u0443\u0434\u0435\u043d\u0442\u043e\u0432.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/monorepozitorii-pozhalujsta-nado\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"en_US\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041c\u043e\u043d\u043e\u0440\u0435\u043f\u043e\u0437\u0438\u0442\u043e\u0440\u0438\u0438: \u043f\u043e\u0436\u0430\u043b\u0443\u0439\u0441\u0442\u0430, \u043d\u0430\u0434\u043e | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0435\u0440\u0435\u0432\u043e\u0434 \u0441\u0442\u0430\u0442\u044c\u0438 \u043f\u043e\u0434\u0433\u043e\u0442\u043e\u0432\u043b\u0435\u043d \u0434\u043b\u044f \u0441\u0442\u0443\u0434\u0435\u043d\u0442\u043e\u0432.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/monorepozitorii-pozhalujsta-nado\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:00:10+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:00:10+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Monorepositories: please, it's necessary | ProHoster","description":"The translation of the article was prepared for students.","canonical_url":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/monorepozitorii-pozhalujsta-nado","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"en_US","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041c\u043e\u043d\u043e\u0440\u0435\u043f\u043e\u0437\u0438\u0442\u043e\u0440\u0438\u0438: \u043f\u043e\u0436\u0430\u043b\u0443\u0439\u0441\u0442\u0430, \u043d\u0430\u0434\u043e | ProHoster","og:description":"\u041f\u0435\u0440\u0435\u0432\u043e\u0434 \u0441\u0442\u0430\u0442\u044c\u0438 \u043f\u043e\u0434\u0433\u043e\u0442\u043e\u0432\u043b\u0435\u043d \u0434\u043b\u044f \u0441\u0442\u0443\u0434\u0435\u043d\u0442\u043e\u0432.","og:url":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/monorepozitorii-pozhalujsta-nado","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:00:10+00:00","article:modified_time":"2019-10-31T19:00:10+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"34744","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 20:28:56","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:15:38","updated":"2026-01-21 20:28:56","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts\/34744","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/comments?post=34744"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts\/34744\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/media\/26181"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/media?parent=34744"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/categories?post=34744"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/tags?post=34744"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}