There are a few ways to handle multiple packages used to create one project. The multirepo model assumes that the packages are located in different code repositories. Monorepo is a single repository that contains and handles different packages. Due to this fact, a monorepo can be mistaken for monolith architecture. However, let’s take a closer look at a project created as a monorepo and compare it with a monolith. We will notice that monorepo consists of multiple logically separated subprojects.
This article will focus on monorepo architecture as it seems like the most modern approach to build complex apps. It is successfully used by companies such as Google, Microsoft, Facebook, and popular projects such as Create React App, Babel, Storybook, Primer, Jest, Strapi and many more.
There are a lot of ways for services to communicate with each other. You could use REST API, GraphQL, SOAP, or even share databases. They all have their pros and cons (especially the last one), and they all share the same problem: coupling. No matter the direction of communication, there is always a little bit of knowledge embedded in your application. The knowledge that you deferentially don’t need (for most of the time). Is there any way to avoid such a horrible thing?
ChakraUI’s homepage states that it's a simple, modular, and accessible component library to let you build React apps with speed. After delivering a few projects where we used Chakra, I can agree with this description. Building UIs never was so fast and convenient. You may already be familiar with libraries such as MaterialUI, Ant Design, or React Bootstrap. And you may be wondering why you need another UI library when you already have a big, battle-tested group of options to choose from. Well, Chakra stands out mainly because of its great built-ins, accessibility, and high customization.