small_avatar_AdrianR3.png

thumbnail_avatar_AdrianR3.png

avatar_AdrianR3.png

Adrian

GET IN TOUCH

In the previous article, we encouraged making certain architectural decisions that can influence the final shape of application architecture. In this article, we will look at popular application architectures and how to create your own solution based on them. We will also identify the GRASP responsibilities presented in the first article within the layers of well-known application architectures.

#### Multilayer Architecture

The most popular multilayer architecture is the three-layer architecture, and its most notable representative is the MVC architecture or Model-View-Controller. MVC divides our application into three layers according to three responsibilities. Let's map them to responsibilities according to GRASP.
![blog-grafika 2.jpg](https://btnw-strapi-prod.dev.btndev.space/uploads/blog_grafika_2_ead357b314.jpg)

- **Controller**: Responsible for coordinating workflow, serving as the Controller in GRASP. It may also be responsible for creating instances of Model objects, thus fulfilling the Creator function, and communicating with the database, which will be realized as Pure Fabrication. In MVC, the Controller is the entry point to the application.
- **Model**: This layer contains data and behaviors that can represent business logic, making it an Information Expert equivalent. The Model can be either a rich or anemic entity. Often, database communication is handled within this layer (instead of at the Controller level). However, it may be a good idea to separate persistence from logic, even if our Model also serves as a database model.
- **View**: Maps data from the model to views returned to the user, performed by Pure Fabrication services. Such a view can be a simple JSON object or a rich HTML view.

A simple multilayer architecture is beneficial in simple APIs where the backend application primarily serves to store and read data. In most cases, we will deal with such applications in simple API implementations within frontend frameworks.

Within the multilayer architecture, we have the flexibility to choose layers. We can often limit ourselves to just two layers, for example, a coordination layer and a business logic layer, where the view is part of the Controller's response. This especially makes sense if we use the previously mentioned CQRS or CQS. The Controller calls operations on the model, which returns nothing, and then queries the repository responsible solely for reading in the View layer.


#### Clean Architecture

Clean architecture is much more complex than multilayer architecture. It also has layers, although they are directed inward, unlike the layers in MVC. The workflow is from the outer layer to the inner and then from the inside out. At the same time, the direction of dependencies remains unidirectional inward through the proper use of programming interfaces (those interested should read about the "dependency inversion principle").

![blog-grafika 1.jpg](https://btnw-strapi-prod.dev.btndev.space/uploads/blog_grafika_1_350cca9c14.jpg)

Clean architecture has three layers:
- **Infrastructure Layer**: Often divided into two layers - ports and adapters, where ports are objects allowing entry into the application (e.g., HTTP controller), and adapters are entries to other devices (e.g., databases or other external services). The infrastructure layer is the outer layer, the only one interacting with the outside world, including dependent libraries or frameworks. This layer handles data reading (Query from CQS/CQRS) and writing. Objects in this layer fulfill Pure Fabrication and Creator responsibilities from GRASP.
- **Application Layer**: A higher layer independent of the infrastructure layer. Its task is to coordinate specific use cases. It is independent of the framework and external libraries. Use cases (represented as services performing one specific task) fulfil the Controller's responsibility from GRASP. Typically, their role is to delegate tasks, fetch and save data to the lower layer and execute business logic code to the higher layer.
- **Domain Layer**: This layer contains domain services and entities (usually rich) that perform operations on data and change the application's state. This layer is independent of persistence, which is delegated by the application layer to the infrastructure. Domain layer objects fulfil the Information Expert role from GRASP.

Clean architecture can effectively separate client business-related aspects from technical details. However, it is quite complex, making it worth using for more complex systems where we will benefit from it.

As can be seen, this architecture involves two models - a domain entity in the domain layer and a database entity in the infrastructure layer. Therefore, layers must map their models when transitioning to a higher layer or receiving data in the lower layer, increasing implementation overhead. This problem does not occur in multilayer architecture, where models are defined in the higher layer to which the lower layer has access.


**What to Choose?**

The appropriate architecture choice depends on the project's complexity and business requirements. Multilayer architecture is simpler to implement, while clean architecture provides better separation of responsibilities and is more scalable. Remember, architecture is like clothing - each project needs an individual approach to feel comfortable and work effectively.

Depending on our project's needs and complexity, we can adapt it. Clean architecture and multilayer (and others not mentioned here) are known ways to handle common issues such as maintainability, testability, and scalability. There is nothing to prevent us from modifying existing solutions and adapting them to our needs. A good idea is to identify the responsibilities defined by GRASP in our code and architecture. This way, deciding how to structure the code will be easier. Additionally, it is worth familiarizing yourself with other GRASP principles that can help us make decisions in grouping and separating responsibilities or prepare us for change.

large_blog-duraj part 3_cover_high.jpg

medium_blog-duraj part 3_cover_high.jpg

small_blog-duraj part 3_cover_high.jpg

thumbnail_blog-duraj part 3_cover_high.jpg

blog-duraj part 3_cover_high.jpg

Backend Architecture on Frontend Part 3


When we were tasked with building a website for Boom SuperSonic, we felt the gravity of the challenge. A groundbreaking aviation start-up, with hundreds of billions of dollars of funding and an aspiration to push the laws of physics to the limit, needed a website that would not disappoint. 

To match their ambition, BoomSupersonic hired a California-based studio, HOO KOO E KOO, to conceptualize and design a powerful web presence. We joined the process to develop a pixel perfect solution.

What is Boom SuperSonic?

From the very beginning Boom Supersonic's ambition has been to allow passengers to travel faster than sound. This dream was a reality in the past but was abruptly ended by Concorde's tragic accident in 2000. 

Boom's flagship airplane - the Overture - was designed to be significantly safer, more efficient and greener than its predecessor. In June 2021, a milestone was reached, as United Airlines announced it ordered the first batch of 15 planes from the manufacturer. 

![ ](\uploads\home-united_2x_3HNaY5HIdoNDhcRs4kYeEc.jpeg)
 Challenges in website development

The designs we received from HOO KOO E KOO stressed the innovative character and seriousness of the project. The site was not intended to be overly complex but had to work impeccably. Think of an airplane manufacturer who cannot engineer its own website...

To reach this goal, our developers used React and Next.js. We paid special attention to the specification we received from designers, spent a considerable amount of time on testing, and brought the website vision to life, just as our client is making their vision a reality. 



small_KHEK_pic01.jpg

thumbnail_KHEK_pic01.jpg

KHEK_pic01.jpg

Boom! How we built a pixel-perfect frontend for a SuperSonic company

**PozTechTalks is a unique series of generally available meetings of practitioners from three leading Poznań technology companies - Apptension, Bitnoise and STX Next. Based on our experience and projects that we have managed, we talk about technologies, good and bad practices, tools we use, business issues and technical details of solutions that we have introduced in projects for our top clients.**

In the third episode of our videopodcast, which we create together with Apptension, STX Next and Krzysztof Kempiński, we talk about:

- browsers API,

- PWA states,

- what's new in recent updates,

- what will happen to PWA when Apple and Mozilla change their policy,

- why web applications are not able to replace native applications? 


**Who creates PozTechTalks?**

- STX Next - the Largest Python House in Europe,

- Apptension - the best combination of design and technology,

- Bitnoise - the specialists for demanding projects.


**Together we have:**

- 39 years on the market

- +496 employees

- + 70 projects per year




PozTechTalks odc. 3 - Nowości na frontendzie

small_Blog_artykul_PozTechTalks_03.jpg

thumbnail_Blog_artykul_PozTechTalks_03.jpg

Blog_artykul_PozTechTalks_03.jpg

PozTechTalks #03: News on the frontend 

**PozTechTalks is a unique series of generally available meetings of practitioners from three leading Poznań technology companies - Apptension, Bitnoise and STX Next. Based on our experience and projects that we have managed, we talk about technologies, good and bad practices, tools we use, business issues and technical details of solutions that we have introduced in projects for our top clients.**

In the fourth episode of the #PozTechTalks videopodcast, we talk about the recruitment process at Bitnoise, Apptension and STX Next. What challenges are we facing? What are we doing to grow without losing the organizational culture? Who is the perfect candidate?

**Who creates PozTechTalks?**

- STX Next - the Largest Python House in Europe,

- Apptension - the best combination of design and technology,

- Bitnoise - the specialists for demanding projects.


**Together we have:**

- 39 years on the market

- +496 employees

- + 70 projects per year




PozTechTalks odc. 4 - Jak prowadzimy rekrutacje na stanowiska frontendowe?

small_Blog_artykul_PozTechTalks_04.jpg

thumbnail_Blog_artykul_PozTechTalks_04.jpg

Blog_artykul_PozTechTalks_04.jpg

PozTechTalks #04: How we recruit for frontend positions

During my career, I worked with many React.js teams and was involved in some way in dozens of projects. Over the years I feel I witnessed enough to say with a degree of certainty what is needed to build a well-functioning, technically precise, and efficient team.

Unsurprisingly, we follow many of those principles and practices at Bitnoise. While you can freely adapt some of them, a few come from past projects and attitudes which is difficult to emulate.

In any case, I hope the below summary will be an inspiration.

So what makes React.js teams truly special?

#### Experience
At Bitnoise, We’ve been part of the React.js journey since its beginning. When it was released in 2013, we already had years of experience in software development. Before the advent of this library, we worked with various technologies where we struggled trying to achieve user-friendly and efficient applications. However, we’re always looking for new technologies to help expedite our work and provide top-notch solutions using the best possible tools.

Over the past decade or so, we’ve watched React.js grow and evolve. Unfortunately, it has become bloated with multiple offshoot libraries making it rather clumsy to use. Consequently, a few challenger frameworks have emerged, including Vue.js.

Lately, we’ve been contented to see that React.js has become leaner, more efficient, and developer-friendly. We can thank the community and amazing frameworks such as Next.js and Remix.js for helping facilitate this change.

As for our role, it’s safe to say that after delivering dozens of software projects, building multiple frontend and full-stack teams, and speaking to hundreds of developers over the past decade, we know React.js inside-out. This technology bears few surprises to us.

Without this experience, we would not be able to build such good teams, and I doubt others would.

![ ](\uploads\Blog_artykul_PiotrB_React.js_blog01_1l87xFkyuQoNZiiA1pNBe0.jpg)
#### True engineering on the frontend
Typically, you might reserve the term “software engineer” for backend developers. And yet, this term fits front-end developers perfectly. It is not about the part of the application they work on or the technology they specialize in. Things like a degree in Computer Science or some other STEM subject are a great background for a great frontend engineer.

That’s why we tend to hire React.js developers with solid, relevant academic backgrounds. Furthermore, we have several backend and full-stack developers on our [team](https://www.bitnoise.pl/team)
. Node.js, Python, .NET, and PHP are just a few of the tools these developers work with. Whenever we work on a front-end project, our developers are always ready for consultation or ad-hoc work.

#### Pixel-perfect mentality
Being capable of expressing every imaginable design through code should be within reach of any good frontend team. To transform [clients](https://www.bitnoise.pl/clients)
’ blueprints into a reality, expert UX/UI designers should work hand in hand with developers. As a client, you can work with these designers one-on-one as they service your project. Otherwise, they should be available for consultations if you provide us with designs from an external agency.

In our case, part of our commitment to perfection comes in the form of our use of state-of-the-art tools for design and collaboration.

- **Figma** is a powerful cloud-based design collaboration tool. As such, it allows designers, product managers, owners, and developers to communicate and collaborate simultaneously. 

- **Storybook** is a workshop where developers can build frontend components and pages individually. This is useful because it enables us to demonstrate and check the component pieces of an application without needing to have the entire view or page ready at once. 

- **QA engineers** test all of the apps we build. At the bare minimum, we run our products through automated testing to ensure that the UX is excellent from day one. 


![ ](\uploads\Blog_artykul_PiotrB_React.js_blog02_1H7vOvuCMd7jNlJjqcps8H.jpg)
#### Bitbucket, Eslint, Next.js and Remix to complement React.js
Cutting edge projects usually take advantage of modern tools to complement React.js and streamline frontend work. As a result, high-quality software is created faster. Here are a few of the tools you might use:

- **Bitbucket/Vercel/Fly.io** for Continuous Development and Continuous Delivery (CI/CD). This toolkit helps us avoid long builds and unnecessarily complex configuration work. I.e., it relieves us of the typical mess and stress that comes with tedious development and QA processes. Furthermore, we like this combo because it provides collaboration tools alongside instant previews – thus leading to rapid iteration.  

- **Eslint/Prettier** for code quality. Linting tools analyze our code and look for errors within it. Since React.js does not have built-in compilers to check the validity and quality of our code, Eslint and Prettier are essential to our development process.   

- **Next.js** and **Remix** for a fast, slick UI. Using these two frameworks, we can optimize interactions even with the most intricate designs. They also help improve the developer experience while we’re coding thus making our jobs easier.  

- **React-Query, Redux-Toolkit, and styled-components** as libraries of our choice.


#### TypeScript
By using TypeScript on top of raw JavaScript, code becomes a lot more consistent. Of course, JavaScript is a scripted language, however, it does not use compilers. Therefore, it’s easy for developers to make errors while coding with it. TypeScript fixes this and makes code more maintainable in the process. Plus, it keeps code up to date with browsers as they change their standards.

Here are some of the many concrete benefits of using TypesScript:

- Increasing team performance

- Easier code management

- Early spotted bugs Increasing code readability

- Easily readable and understandable components


#### SEO mindset
Regrettably, raw React causes some issues with search engine optimization. Sometimes, search engine algorithms will shun pages built on React - especially if they’re a single-page application. We resolve this problem with Next.js. Since Next.js permits rendering React applications server-side, the SEO issue vanishes.

#### Community and knowledge sharing
Best teams are not the ones who become isolated from the rest of the world. Learning, teaching, talking to others, inspiring them, and helping others in the software community brings in a lot of new energy and motivation to developers.

In our case - the commitment to education is everlasting. We’re constantly investing in professional development and growth at every level. Here are some examples of our philosophy in action that may help your teams grow too:

- **Internal training**, which is directed and delivered by our senior developers or an external specialist.

- **Bitnoise Meet** is a learning initiative we began to encourage education and research in our field. In doing so, we invite professionals from other companies to learn alongside us.

- **PozTechTalks** is a series of podcasts and videocasts that we coordinate with other local software companies in Poznań. During these sessions, we discuss advanced computing concepts and challenge each other on our perspectives.

- **Land on Moon** is a meetup initiative where CEOs, founders, and product owners share their inside stories from the software development industry.




Blog_artykul_PiotrB_React.js_blog03.jpg

Blog_artykul_PiotrB_React.js_blog04.jpg

Blog_artykul_PiotrB_React.js_blog05.jpg

Bitnoise_events

I hope those hints will help your team become better and happier. If you’d like to work with me or my colleagues check out some of the services we offer and do not hesitate to reach out to us.

- [React.js teams](https://www.bitnoise.pl/services/remote-react-js-teams-next-js-typescript)
 

- [CTO as a Service](https://www.bitnoise.pl/services/cto-as-a-service)
 

- [Process consulting](https://www.bitnoise.pl/services/software-development-process-consulting)





small_Blog_artykul_PiotrB_React.js_blog_cover_high.png

thumbnail_Blog_artykul_PiotrB_React.js_blog_cover_high.png

Blog_artykul_PiotrB_React.js_blog_cover_high.png

What do best React.js teams have in common?

Adam Misiorny is a Frontend Engineer and Tech Lead at Bitnoise. Since Adam is one of the most experienced software developers on our team, we thought he would be the perfect person to offer insight into how our different developers cooperate during their work.

#### You are a leader, but what exactly is your role in your current project?
At the moment, I’m a Frontend Principal Engineer in a long-term project with JOIN. This means I have the most detailed knowledge of the project and the associated systems. As a result, I’m the one who makes decisions regarding development directions and front-end architecture. It’s a big responsibility. Sometimes, I work on developing the platform itself, but mostly, I’m in a leadership role.

From the perspective of the front-end developers working alongside me, my task is to accelerate product development and render it as efficient as possible. Since I am tasked with ensuring efficiency, I also get in the trenches and help solve complex problems should the situation require it. I’m always of use to other developers.

#### As a Frontend Principal Engineer, do you take part in onboarding new developers at Bitnoise?
Indeed, I often introduce new developers to the project. I take an active role so that each developer can get started working on our products quickly and eliminate onboarding uptake time.

Part of this onboarding task is to acquaint developers with our application architecture and coding standards. This helps light the path forward for quality work to get done. Under my watch, developers familiarize themselves with the common processes we use with each project. These range from pull requests to production deployment.

#### And how do you work with new developers in the project?
I assign each of my junior and middle-tier developers a senior “coding buddy” who assists them with their daily tasks if necessary. As the Principal, I supervise the developers at the review stage with an emphasis on the initial stages to ensure that we set the right tone. Should any of my developers have an inquiry, I am quick to answer them and assuage their doubts.

My role as a consultant is one of the most critical parts of my job. I need to give every developer context as to why we approach each problem a certain way. Less experienced developers soon absorb our general programming ethos at Bitnoise as a result. Understanding is the key to growth.

![ ](\uploads\Blog_artykul_Adam_React.js_02_BZ72URItqw8KOX2g07eZS.jpg)
#### What surprises you about working with less experienced developers? What attitude do you expect from juniors and mids?
While I am usually busy shepherding young developers, it’s not uncommon for me to learn a thing or two from them myself. My experience is a major asset, but that can sometimes mean that my programming approach is rather fixed. I benefit quite a bit when I receive fresh perspectives from young computer science graduates. Our work is enriched when I can look at an issue from a different angle.

Above all, I prize developers who have a passion for learning. Anyone who hungers for knowledge can be taught anything, making them more adaptable as programmers. It’s no use trying to force-feed solutions to a disinterested developer. You can lead a horse to water, but you can’t make it drink.

#### What keeps you in Bitnoise for so many years? If I'm not mistaken, this year we'll be celebrating your 10th anniversary at Bitnoise!
It’s a fantastic atmosphere. Isn’t it? After 9 years of working here, I still haven’t tired of my role. And I’ve grown along with it. Even as Bitnoise has evolved and grown, the team spirit has never changed.

When I was a young programmer, I worked on several projects with diverse topics. Consequently, my breadth of programming knowledge skyrocketed, and today I am happy to say that I have experience that ranges the entire spectrum of software development.  Once Bitnoise assigned me as the leader of a long-term project, I appreciated the new stability. It felt as though I had been preparing for years for this role given my work in so many different fields. After 4 years of working with JOIN, I still haven’t grown bored of the project – it keeps me on my toes as I learn new ways to solve the problems we encounter.

If you’re looking to work for a stable company where you can grow your programming skills, I highly recommend working at Bitnoise. The atmosphere is, as I said, top-notch. Personal development is a priority for all of us.



small_Blog_artykul_Adam_React.js_cover_high.png

thumbnail_Blog_artykul_Adam_React.js_cover_high.png

Blog_artykul_Adam_React.js_cover_high.png

How do mid and senior React.js developers cooperate at Bitnoise?

React has been around for a while, and it is currently the leading frontend framework (ok, library). It somehow manages to stay ahead of the pack despite tough competition. The React community is massive and that in itself is a good enough reason to expect a framework to stay popular as the adoption curve cycle slowly plays out. This sort of drift, however, is definitely not what’s happening with React. In fact, React stays popular because it keeps reinventing itself in the attempt to answer the changing needs of UI engineering (and, for the most part, does so gracefully, without compromising backwards compatibility).

This article looks at React's latest attempt to chart a new course, this time by laying out a bold vision around extending the component ecosystem into the server with **React Server Components**. The technology is not yet fully production ready, but you can already test early implementations offered by Next.js (and Remix might soon follow suit), and so it is probably mature enough that decision makers in companies using React (or considering using React) should start paying attention. 

First let’s understand the challenges the React team is trying to address and then look at potential adoption challenges and how the way we build and structure teams of React developers going forwards would change should the vision be brought to fruition.


#### **Why is React evolving towards the server side?**
It may come as a surprise if you’ve worked with react for years, but the React team now recommends to start new React projects through fullstack React metaframeworks:

![ ](\uploads\blog-serverReact_post_01_7EIWdEC0ow4M5qFf65l5pA.png)
*Source: react.dev*

The emphasis on using a framework is such that they felt it necessary to preempt the question of whether React is still its own thing.

![ ](\uploads\blog-serverReact_post_02_6XqaSpCjS2vNDLNmmc5Vy2.png)
*Source: react.dev*

This is quite a shift, considering that for the longest time the recommended solution was to use CreateReactApp - a tool built by the react team which spins up a React SPA (i.e. a client side only app). **What explains that change?** In short, React Server Components. Answering this question in a bit more detail is still rather challenging though, because – while the authors know the answer very well – they’re still figuring out the best way to communicate this to the outside world in a way that would capture people’s imagination. Luckily, **Dan Abramov from the React core team has lately given us a sneak peak** of their thinking by testing some pitch ideas for React Server Components on his private twitter account.

![ ](\uploads\blog-serverReact_post_03_7Ct4KhNuhk4eZXZDX0I28K.png)
*Source: Twitter*

You can read the whole thread here:

["i need to start collecting ways to pitch react server components.](https://twitter.com/dan_abramov/status/1631885118355718144?lang=en-GB)
"

But here’s my top 3.

#### **Best pitch for Server Side Components: 3rd place**
![ ](\uploads\blog-serverReact_post_04_jsP1HQs3YXsp6dBnnm21l.png)
*Source: Twitter*

This one, Dan readily agrees, is a little hyperbolic - but then most good sales pitches are. It gets third place because it’s rather inaccurate, but it does communicate the promise of having to think about getting data as part of architecting your UI much less often. 

Currently the data fetching pattern the react team has converged on is all about favoring collocation of components and data fetching, i.e. each component knows what data it needs and fetches it as required. There are many benefits of this approach, full composability being probably the largest. The drawback is that, since all that fetching happens on the client, each component triggers its fetching logic only once it gets rendered, which depends on the ancestors having been rendered and having fetched their data etc. - a waterfall of queries ensues, and the need to cache and dedupe requests on the client presents itself very quickly as the app grows. 

In Meta (React’s mother company) that is handled by the Relay framework, which facilitates stitching together a top level GraphQL query based on data dependencies declared locally by every component. It then takes care of optimizing a single top level query, which includes deduplication (the same data requested by multiple components gets requested once). Relay is a very powerful solution, check out this talk by Robert Balicki from the React Data Team to learn more: [https://www.youtube.com/watch?v=lhVGdErZuN4](https://www.youtube.com/watch?v=lhVGdErZuN4)


While RSC and Relay are very different things and might be used in conjunction, **they do have an overlap when it comes to solving request orchestration and deduplication**, i.e. in both cases developers worry less about optimizing data fetching. 

Here’s another tweet from Dan, which sadly didn’t make it to the top three: “**read data on the server, pass it down by props**”. This means developers would essentially be able to “think in components” also on the server. With React Server Component you can simply await a promise inside a (server) react component instead of fetching from the browser. 

The best part is that you’re not limited to treating your server components as “all knowing parents” responsible for getting all the data children need (which is what route level fetching in Multiple Page Applications is). Instead, you can be as granular as you want. You might choose to place a server component at the bottom of the React tree even if it has client rendered ancestors. Hopefully this illustrates why React developers in the future might worry less about using APIs and instead focus on the best ways to combine components, each of which would handle their own fetching concerns, with the actual fetching benefiting from some optimizations higher up.


#### **Best pitch for Server Side Components: 2st place**
![ ](\uploads\blog-serverReact_post_05_6oyCT94PSinGhUFajfUJ25.png)
*Source: Twitter*

This one is the key to understanding why building server first React components sits well specifically with React. The concept of facilitating the component based UI architecture paradigm both on the frontend and the backend is not limited to React but React’s unidirectional data flow is especially well suited to play well with such a setup. 

React treats the UI primitives like they are just values. You can keep them in variables, pass them around and compose them into larger groupings that behave predictably precisely because data flows through them only one way.

![ ](\uploads\blog-serverReact_post_06_4DCvJN1QEpawIimpDTpJpr.png)
*Source: Twitter*

Subsections of the component tree get selectively rerendered as required in order to reflect changes in data. It is therefore important to control at which level of the virtual dom tree the data changes are detected and reacted to. React developers know this problem as “lifting state up”, i.e. moving a piece of data as high up as necessary (closest common ancestor), but not higher (to avoid unnecessary rerenders). 

Now thanks to React Server Components developers can design their state architecture the same way but they can now decouple the problem of component structure from the challenges of sourcing the data in a streamlined fashion. 

With RSC, what arrives in the browser is a serialized json describing the react tree with the server side components already broken down into base html tags containing the results of any data crunching that happened on the server (it also contains elements acting as placeholders for client side rendering). There is no rerender triggered by the fetched data suddenly arriving somewhere higher up in the tree. In this sense, the server data orchestration serves as the top level of the unidirectional data flow, even if the components themselves are deeply nested in the react tree structure and have client rendered ancestors. Powerful stuff.

#### **Best pitch for Server Side Components: 1st place**
![ ](\uploads\blog-serverReact_post_07_5rVtbB7A2yPrv3agQ2Dp2r.png)
*Source: Twitter*

This pitch idea hits the nail on the head, I think. It’s all about still thinking in components but extending the composability. SRC is an entry point to the future where react components can be published on NPM and have their own data fetching concerns fully met out of the box rather than having to rely on app developers to understand what data is needed. 

This is the benefit that is much more interesting to CEOs than the details of how this is actually achieved. Imagine how much more streamlined the work of large react teams becomes if components can handle their own data in a way that allows you to put them together in more complex groups without footgunning yourself. 

That vision is definitely appealing. So, what are the drawbacks and challenges we might expect should it be realized?

#### **Fullstack React: added complexity vs metaframework lock-in**
The already mentioned emergence of react meta-frameworks, i.e. frameworks built on top of React, is not a problem in itself - on the contrary - next.js, remix and other frameworks have a lot to contribute. 

That said, React team deferring to these frameworks as a way to start an application tells you something about the fact that delivering on the vision outlined above no longer sits solely within the remit of React. The bits frameworks care about now become an integral part of delivering your UI to your users. What follows is that you might have to acknowledge that choosing React as your UI technology will now have potentially further reaching consequences and may come with added complexity. In other words, choosing React is no longer just choosing one of many flavors of V in MVC. 

This sounds like a lot of additional headache, doesn’t it? It doesn’t have to be! The whole point of the shift towards starting with a slightly more complex setup than just a SPA means that **you’re not locking yourself into a SPA** - and that’s a huge benefit as it saves you some serious grief in the future. Adding all the server-y bits to a bloated SPA is a complex endeavor. To avoid it, you may want to start with running RSC at build time (so react server components but – sort of – without a server) and then shift towards using whatever mode makes sense on route by route basis (and yes, there is a Dan Abramov tweet to back this up too). 

Does it mean that you should marry a metaframework? Maybe, and maybe not - either way, it’s now up to you to understand what such a framework does for you, and the answer is no longer simply based on whether you need SEO and hence need SSR. By the way, RSC is not the same as SSR. Server side rendering can be set up to play nicely with React Server Components though, and that’s partially also what metaframeworks do for you. 

One thing to consider is that server rendering runtimes are now a thing. As your UI app no longer lives solely in the browser, hosting becomes potentially more complex than just dropping a SPA bundle on a CDN. UI architecture considerations would now need to extend to deciding what your SRC server rendering environment requirements are. For example, Next.js now offers three different server rendering runtimes (node, node serverless, edge) - each with its own characteristics when it comes to security, latency, scalability and IO access and each with its own tradeoffs (e.g. code ran on the edge cannot exceed a certain size etc.). If you don’t want to be married to Vercel (the hosting company behind Next.js) - you need to roll your own. If you don’t mind tying yourself to a hosting provider, that has consequences too. 

Another thing to consider is that with SRC bundlers play an increasingly important role. Your bundler would now be tasked with generating serializable “module reference” objects, i.e. creating the server side placeholders for client rendered components, and then helping the client stitch the tree back together following the client rendering step. If you bootstrapped your project with a metaframework, this won’t be an issue. If you’ve got your own bundler setup, it might be something to look into. 

Yet another consideration is caching your rendered components (see static vs dynamic rendering in Next.js for an example of that). You might also be curious if your “backend for frontend” can rely on other technologies than javascript (not yet as far as I know, but that may soon change) and so on – there are potentially many more such technical challenges, which fall outside of the scope of this article. We’ll surely discover even more once the technology is mature enough to be production ready. 

What is obvious already, however, is that all of the above potentially impact the way you should source technical talent for react teams. Let’s look at why that is.



#### **What fullstack react means for sourcing React talent**
If the react community does embrace the metaframework first approach, one immediate consequence is that React skills will become less transferable. Familiarity with React via Next is not necessarily going to equate to familiarity with React via Remix - not to mention that we can expect to see meta-metaframeworks, i.e. more domain specific frameworks to be built on top of metaframeworks (e.g. Shopify hydrogen 2.0 is built on top of Remix). Each metaframework offers different abstractions and each is going to be incentivized to differentiate its offering. Competition is always great for end users, but bear in mind skill transferability may suffer. In your hiring you may therefore be well advised to pay more attention to the understanding of the underlying server related concepts, not framework trivia. 

Another consequence is that - metaframework or not - the mental model of react stretched across the network boundary becomes increasingly complex when it comes to debugging, optimization etc. Also, marrying the current client-heavy toolset with SRC may prove challenging. For starters, here is Jack Harrington building a toy Next.js 13 app using redux toolkit both on the client and the server and initializing the client store with values from the server store:

State Management for NextJS 13 Server and Client Components by Jack Herrington

This is to say that spreading React both on the client and the server may yield new challenges which you may want to test for or upskill towards. 

At this stage you may ask: is it worth all the hussle of revamping your HR practices just because one framework came up with a new feature? My answer in this particular case would be yes, if you believe this trend is wider than RSC - and I believe it is. 

Consider for example, that the same trend has been playing out in the C sharp world. .Net developers discovered the benefits of component based composability by going from MVC and razor pages to the Blazor framework, which came in two flavors. Blazor server, offering server rendered UI components, and Blazor Web Assembly, which works pretty much like every other SPA framework but relies on .net instead of javascript, crammed into the browser courtesy of webassembly. 

Now with .net eight on the horizon there is a new flavor of Blazor in town, called Blazor United, which promises to give developers the best of both worlds by allowing them to define which components should render on the server and which should be treated as client components. Sounds familiar? Here’s Jon Hilton explaining the details of how Blazor United came to be, and comparing it to Remix: [https://jonhilton.net/blazor-united/https://jonhilton.net/blazor-united/](https://jonhilton.net/blazor-united/)


This is not to say that server heavy UI frameworks are somehow a historical inevitability. The split between frontend and backend development is a valid one - at least for larger organizations. However, what seems to be more and more evident is that this split doesn’t align with the split between the server and the browser as neatly as we once thought. Instead the fault line seems to be between UI related concerns (spanning both server and frontend) and non UI related concerns. The talent sourcing consequences are pretty obvious if you look at it this way, and they go well beyond React. 

#### **Summary**
It’s still early days for RSC but it seems like it’s time to start looking at the details of what server-first React means for our organisations. 

#### **About the author**
[Jan Bełezina](https://www.linkedin.com/in/jan-belezina-7356055a/)
 is a software engineer and guest blogger for Bitnoise, based in Oxford. He specializes in React, Three.js, Next.js, and TypeScript. As a former product manager and business analyst, he has a wide overview of the development process and strategies.

small_blog-serverReact_cover_high.png

thumbnail_blog-serverReact_cover_high.png

blog-serverReact_cover_high.png

The server-first future of React – guide for CTOs

If you have a million-dollar idea, you want to validate it as quickly as possible. Spending time on things that don't add much value can be wasteful, so it's important to be strategic. Component UI libraries can help you create your MVP quickly and efficiently. 

#### Tools tailored to your requirements

There are plenty of solutions in the market that help with that, and each of them will fit different needs. 

Bootstrap has been around for quite a while and is well-known in the web development world. It was created to make it easy to build responsive web apps. It is basically a simple CSS library, but it got integrated into many popular libraries and frameworks like React or Angular. 

Material UI draws its inspiration from Google's innovative design philosophy, "Material Design," which emphasises user experience, depth, and visual consistency. Its main focus is customization, allowing developers to create interfaces tailored to their specific needs. Based on that, you could create your own design system that would fit your needs exactly as you want it.

If you’re looking for more enterprise-level solutions, Ant design might be a better choice. It offers a big collection of components designed to facilitate the development of complex business applications, which include sophisticated interfaces for data tables, forms and charts.

Chakra UI prioritises developer experience through its modular, customizable components. It allows you to define and apply themes, promoting code reusability and ensuring a consistent look and feel across elements. However, it is less known than the predecessors, so the community might be a little smaller.

While established solutions have a track record, their designs may appear dated. If you're aiming for a modern look and feel, Next UI is a compelling choice with its focus on aesthetically pleasing components. Plus, they made sure it runs fast by using Tailwind CSS as the core, which cuts down on the extra classes in the bundle.

Considering the advantages and disadvantages, most of the solutions are similar, and by the end of the day, it could be a matter of personal choice. Let’s dive in and see the use of specific components to assess the developer experience.

#### Compare different components

In the next section, I will compare specific components, showing which features are available by default and which are not. Take into account that most of the things mentioned could be somehow implemented, however, I will focus only on the aspects that are handled by the library.

#### Commonly used component

I think the Button is the most used component from such libraries, so it would be best to start the comparison with it.

![tabelka 1_.png](https://btnw-strapi-prod.dev.btndev.space/uploads/tabelka_1_63332c5fbb.png)

All the component UI libraries support different button variants such as primary, outlined or of different colours and sizes. Managing the state can also be achieved by all of them, however, Bootstrap needs a little more code to be written around the logic of the loading state. Bootstrap also lacks icon support, so if we want to implement that, we have to manage it ourselves. 

#### A more advanced example

I think working in modals can be either pleasant or a nightmare, depending on the specific developer experience the tools provide. Seeing what features different libraries could offer can help us understand what would be easier to use in the long run.

![tabelka 2_.png](https://btnw-strapi-prod.dev.btndev.space/uploads/tabelka_2_1fa58e692d.png)

Compared to Button, here we can actually see some significant differences between the libraries. Ant Design simplifies the most common use case for models, which are confirmed dialogues. It provides an additional confirm function, which takes only texts and callbacks, allowing us to trigger it anytime we need it without focusing on defining content each time. This library also handles async logic, so calling APIs and showing its effect could also be simplified. Another difficult case would be modal nesting, which is supported by Material UI and Ant Design. This could facilitate handling of some complex business flow. Material UI also lets you drag modals around. It's a handy feature, but personally, I don’t see much use in business contexts.

#### What to choose?

With so many libraries on the market, choosing the one that works best for you can be challenging. If your design is simple, it is probably a matter of personal preference. With more complex applications, it would be good to assess if there are any specific harder use cases that some of the libraries might support better than others.

large_blog-DecodingReactUI_cover_high (1).png

medium_blog-DecodingReactUI_cover_high (1).png

small_blog-DecodingReactUI_cover_high (1).png

thumbnail_blog-DecodingReactUI_cover_high (1).png

blog-DecodingReactUI_cover_high (1).png

Decoding React UI: Unveiling the Best Component Libraries in a Head-to-Head Showdown!

### Cracking the Code: TypeScript Tips & Tricks to Catapult Your React Application

#### Introduction

Every project that uses Typescript under the hood will contain some custom types that are being used across the application. As an application evolves or demands shift, it's important to manage all those types in accordance with DRY and KISS foundations. In the name of type safety, it might be tempting to type every single element within the codebase. However, it can be beneficial to stop for a minute and ask those 2 questions:

- **Why** is there a need for a given type?
- **What** is it needed for?
- **Where** will it be used?

It's important to note that creating too many custom types can lead to the over engineered codebase. When one change request or a new feature requires updating x amount of custom types, it can make the codebase harder to maintain.
This blog post will cover some useful tips and tricks to add to the cauldron of typescript magic to keep in mind when working with custom types.

### The less typescript, the better

Excessive inclusion of types for every single data structure may seem like a good thing at first. However, having a lot of custom types can lead to an unnecessarily bloated and redundant codebase, where some types may be duplicated unnecessarily.

To better understand why often less is more it's best to show by example:


At first glance, the above code looks good. Everything is type safe, but this code can definitely be improved.
By following the three questions asked in the introduction:

- **Why** is there a need for `ParsedUser`? - So that an array returned by `parseUserData` could be used in different places in the codebase.
- **What** is `ParsedUser` needed for? - To have a simplified type of `User` type.
- **Where** is `ParsedUser` used? - For example, in some components' prop types.

Doing one thing at a time. `ParsedUser` is just a simplified version of the `User` type, so it makes sense that when `id` or `username` on the `User` type changes,  `ParsedUser` would also adapt.

This can be achieved by introducing typescript's built-in utility types. It's possible to reuse the `User` type to construct the `ParsedUser` type by using `Pick`.


With that small change, `ParsedUser` and `User` are "connected" so whenever `username` or `id` changes the `ParsedUser` will also update.

The next thing to consider would be how to handle the return type of the `parseUserData` function. If there ever will be a need to change the shape of `ParsedUser`,  e.g. adding a `fullName`. With the current state of the code, every change to `parseUserData` must be followed by updating the `ParsedUser` type, which may not be ideal.

Since `ParsedUser` type is closely related to what `parseUserData` returns, it's possible to use `ReturnType` utility type from typescript and create this type like so:

Two things have happened:

1) Typescript is smart enough to understand what types will be returned from a given function so it's possible to skip it in function declaration.

2) By using the `ReturnType` utility, the `ParsedUser` type will not only be dependent on the `User` type, but also on the `parseUserData` function. When the shape returned by `parseUserData` changes, the `ParsedUser` type will reflect that change as well.

  
_As an addition, it is still possible to use this approach with async functions by introducing yet another utility type `Awaited`, e.g._


_Adding [number] to array type will tell Typescript to look on type of an item within that array._

As the above example presents, with less typescript the code is still type safe AND highly adaptable to any changes.

Utility types used in this example are just the tip of an iceberg.
In typescript's documentation, there are   way more utility types that can lead to enhancing the implementation of custom types and reducing the number of types needed in the application.

[https://www.typescriptlang.org/docs/handbook/utility-types.html](link)

### Master union types

A type union is most commonly used when a given property can have more than one type or when creating a custom type.
Basic type unions could look like this:

However, type unions can also enhance the developer experience when working with React components.
Again, best explained by example:

This example is invalid because `UserCard` requires to pass both `userStatus` and `adminStatus` no matter what user role is passed. A better experience would be to require passing the `userStatus` only when the user's role is `USER` and vice versa.

Possible fixes would be:
- Make both `userStatus` and `adminStatus` optional, but that may not be the intended behavior of `UserCard`.
- Create a separate `AdminCard` for handling admin stuff, but that can lead to code duplication, which could violate the DRY rule.

In this simple example, it would not be the end of the world to make `adminStatus` and `userStatus` optional. Oftentimes, components have more complex structures and making a lot of optional types can make it harder to understand what components require and when.

There is a better way of solving this issue with both type unions and typescript magic:

By extracting the common properties (`fullName`) to separate type and creating additional two separate types joined by union `UserCard` now have props that will be required based on the provided `role` prop.

_Typescript will know that both types used in the union have a role property, so it will "merge" these into one type. In the end, the role will be of type "USER" | "ADMIN"._

This behavior improves the developer experience, when working with this component because it requires different props depending on the user's role.

With great power comes great responsibility, so this pattern should be used wisely as it has some drawbacks:
- it can make props type less readable
- can be difficult to implement when there are two or more props that change the outcome overall props shape

#### Generic types for not a generic dev

Implementing generics enhances the flexibility and reusability of code segments within a codebase. This typescript is a fundamental tool that developers should frequently reach out for, becoming an essential tool in the toolkit of every developer working with typescript.

Generics can simply be used to create custom utility types e.g.


Function `swap` can only be used with strings, but what if there is a requirement to swap numbers, or some other custom typed data? It's a good idea to make this function generic:

_Specifying return type [T, T] makes sense here, because this array will always consist of just two elements._

Now this function can swap not only numbers, but any data thrown in as arguments.

When working with React, generics can be used to create generic components f.g
instead of creating Lists components for every single array the codebase has, it can be done with one generic component:

_Thanks to adding <T extends { id: string }>, id which is used in item's key will be required part of item type._

The list can now be used with any type of data structure, which makes it a highly reusable component.

#### Summary

TypeScript is approachable for beginners with its gradual typing and JavaScript compatibility, but mastering its advanced features like typing nuances and generics can be challenging. Despite the learning curve, the benefits of static typing lead to more reliable code, better collaboration, and reduced bugs. TypeScript's robust tooling and community support further enhance its appeal. The initial ease of use gives way to long-term advantages, making it a worthwhile choice for developers aiming for code quality and maintainability.

Typescript is easy enough for beginners to start their journey with static typing, but some more complex features (generics or type unions) can be hard to get around at first. Still, they can improve the maintainability and reusability of some parts of the codebase, so it's worth getting to know them.

I hope this blog post will ease the learning curve of the more complex topics of Typescript.

large_blog-DecodingReactUI_cover_high (3).png

medium_blog-DecodingReactUI_cover_high (3).png

small_blog-DecodingReactUI_cover_high (3).png

thumbnail_blog-DecodingReactUI_cover_high (3).png

blog-DecodingReactUI_cover_high (3).png

Developer is sweaty, TypeScript spaghetti


Git is a fundamental tool that every developer must have in their arsenal. In a modern and agile world of software development, where codebases are managed by huge teams, having a tool that helps to streamline the process of adding features, changes, or fixes is, without a doubt, a necessity.

Like many tools, git is, with no exception, easy to learn and hard to master. In just one day, an inexperienced developer can learn how to connect to a remote repository, create a branch, push commits, create pull requests, and merge the code. This blog post aims to help developers become more mindful about what and when is being committed to keeping the history well organized, informative and clean.

Keeping the commits history clean helps understand what changes were made to the codebase to backtrack easier if something is not working properly. Not having descriptive commit messages or having too many changes in a single commit are common issues of larger codebases.

![blog-DecodingReactUI_blog_01.png](https://btnw-strapi-prod.dev.btndev.space/uploads/blog_Decoding_React_UI_blog_01_8c93667a61.png)

#### The easy parts

Every developer knows these commands by heart:

These commands are the foundation of working with Git. However, some of these commands can be slightly modified to create better commits.

##### git add

When working on a new feature, it is often hard to stop in the middle of the process just to create a commit. After some time, the feature is fully implemented. X number of files have been altered, and Y files were added. The time to commit code has come. Instead of creating one big commit, it is often better to have multiple smaller ones, e.g., creating a UI component, creating a test case, updating the types, etc. But the work is already done, so how can one split it now?

Simply by adding `-p` (patch) flag to `git add` command will open an interactive window that will go change by change (it **will not** go through newly created files). Developer will be able to decide whether or not to add given change, skip it or break it down even more. Now all changes regarding the tests, creating new ui components or updating the types can be separated into a different commits. Same file can be committed multiple times containing different changes that are part of a given commit, thus bringing it one step closer to create a clean commit history.

##### git commit

Now that the bigger changes can be grouped into smaller chunks adding a descriptive commit message is next in order.

Adding one `-m` flag will create a header for the commit message that will be shown in the history. However, sometimes one liner is not enough to fully describe the changes because more context is required. Adding another `-m` flag will create a commit's description:

When running the `git log` to display the commit history, it will be displayed as so:

_To quit the git log command, click 'q' on the keyboard._

Descriptions can be improved by adding `$` before the description to introduce better text formatting.


_Adding \n creates a new line_

This will be visible as:


Not every commit requires a description. It is always up to a developer to consider if changes that are being committed require more context or not.

_At Bitnoise, we follow the guidelines laid out by the [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/) to ensure that our commit messages are well structured. This ensures that commits in the history have a similar structure, making them easier to read._

There can be cases where the commit was made, but there was a typo in the code, or some small improvement was still missing. Instead of creating a new "fix typo" or "remove console.log" commit ```--amend``` flag can be used.


It will add all new changes to the last existing commit, so it's super useful for small updates on the last commit (how to update commits that are higher in the history will also be covered later in the blog post).

_Amending will change the commit hash, so if the commit has been pushed to the remote branch, it will be required to force push; thus, amending on shared branches must be avoided!_

#### Bringing it all together

Moving changes from one branch to another is a crucial part of working with git. It serves three purposes:

- shared branch can be merged to a local branch to have it up-to-date with the latest changes made by the rest of the team,
Local branches can be merged into a shared branch to make the new feature or bug fix accessible to other developers in the team (usually via pull request).
- local branch can be merged to another local branch to have them up-to-date

These cases may seem the same at first - making one branch up-to-date with the changes of the other. However, there is an important difference between the shared branch that is being used by the whole team and the local branch that's being used by one developer. The difference is that on a shared branch, the commit hashes should never change (pushing with force should never be required). On local branches, commit hashes can change (until the changes are not merged to the shared branch), and it will not impact the team's work.

In those scenarios, the developer has access to two different strategies: **merging** and **rebasing**.



**When is it safe to rebase?**

- when updating the private branch with the shared / main branch to preserve linear history.
- When making changes to the commits made on the private branch that are not a part of the shared branch, e.g., editing commits, rewording commit messages, squashing commits, or deleting them.

**When is it not safe to rebase?**

- when working on a shared branch like development or main, it's always better to use merge over rebase to ensure that commit hashes will not change and no forcing push will be required. If merge commits are not needed, `git merge branch-name --ff-only` can be utilized to merge changes without adding the merge commit.

  
##### Interactive rebasing

Where rebase surely shines is the interactive version, which can be used to alter the commit history in many ways.

_ n - number of commits in the history to take into the rebasing from latest to oldest f.g if two latest commits should be rebased, then n = 2_

Interactive rebasing allows you to edit committed files, reword commit messages and even squash or delete commits.

When running the command, it will show a window that can look like this:


For example, above following actions can be utilized to organize the commits better:

_When editing a commit, after editing was finalized, `git rebase --continue` should be executed to move to the next commit_

Rebase will go through each listed commit, execute the desired action, and after completion, replace a commit, thus **changing commit hash**, and move to the next one.

_If the commits were already pushed to the remote branch push with force will be required._

When a need arises to edit a commit message or whole commit that is not the latest one (the latest one can be updated by amending with `git commit—-amend`), interactive rebasing truly becomes handy.

#### More is not always better

On the other hand, having 30 commits for a single feature or bug fix might be an overkill and reduce the history's readability rather than improve it. Sometimes, it makes more sense to join or squash some commits into one bigger commit with more substance.

For example:


The commits above are very granular, and it does not make sense to have them separated like that. One can leverage interactive rebasing to squash these commits easily.

The end result may look something like this:

Now, instead of having multiple remove console.logs, typo fix commits can be organized into one big, easy-to-understand commit.

#### Conclusion

Many developers stop learning git after understanding the basics, which can negatively influence the team's work. Clean history is a part of code documentation and improves not only tracking what was done and when but also reviewing the code in pull requests. Tracking where something could've gone wrong when bug fixing is also less painful if commits are well organized.

This blog post shows that small changes to well-known commands can drastically improve the quality of the commits being created. Adding interactive rebasing into the mix will also make any developer an even better team player.

#### Useful tips and tricks

##### Git game

If you're a beginner and those topics still appear too advanced, you may want to check out this [game](https://learngitbranching.js.org) to familiarize yourself with the git basics.

###### Editing name of the branch

Sometimes, a typo can sneak into a branch when creating it. So here is a flow that will allow me to edit branches to fix the typo. 


##### Removing all local branches

When working on a big project, sometimes a lot of old branches can be deleted. Instead of going branch by branch, this command can be used to delete all local branches:

large_blog-DecodingReactUI_cover_high.png

medium_blog-DecodingReactUI_cover_high.png

small_blog-DecodingReactUI_cover_high.png

thumbnail_blog-DecodingReactUI_cover_high.png

blog-DecodingReactUI_cover_high.png

Git Gut: Take care of your commits history like a pro

#### The Story Repeats Itself

When I started my programming journey, I was simply a Web Developer. I was responsible for both frontend and backend parts, communication between them, and often for deployment and maintenance as well. Over time, however, these roles began to specialize, and people started focusing only on certain parts of the development process. This specialization was necessary since the complexity of systems has been growing, making it harder to understand, develop, and maintain the entire software stack. This complexity stems from more than just business logic but also from the myriad of technologies, tools, libraries, and frameworks. However, it turns out that having many specialized professionals is sometimes not cost-effective for projects of a certain scale. This gap has been filled by frameworks like Remix and Next.js, which are full-stack frameworks offering both frontend and backend programming capabilities.

#### However, Here Lies the Problem…

The cycle has yet to come full circle. The emphasis has shifted. In the past, frontend applications were secondary to backend applications. The backend would generate HTML for the frontend, and over time, with the advent of browser scripts, this trend started to reverse. In many contemporary applications, the focus is now on the frontend. This shift depends on the type of project and the complexity of its components. Sometimes, we deal with a simple interface and a complex API, while other times, both are equally complex or simple. However, the problem that frameworks like Next.js solve is when we have a complex interface and a simple API, which can be compared to a data repository. These frameworks allow us to quickly program a complex frontend application and the necessary backend application. In such cases, it's advantageous to have a developer who can handle both sides, saving a lot of time and money by avoiding the need to create a separate API. In this scenario, a frontend developer is the obvious choice. However, with specialization towards the frontend, backend skills are often neglected, resulting in a backend that becomes unmanageable, with complexity growing and resembling spaghetti code, while the frontend code remains clean and consistent.

#### Why Does This Happen?

Frontend applications have a different nature compared to backend applications. The architecture is inherited from available frameworks and libraries, implicitly guiding the developer. Although this approach can backfire in the long run and become unmanageable, it's better than having no architecture at all, especially when we are unsure how to design one sensibly. This is the situation we face on the backend side with Next.js or Remix. These frameworks offer us an entry point to the backend, automating communication via AJAX so we don't have to manually integrate it. However, they don't provide us with a structure within which we can operate.

#### Let's Introduce Some Architecture!

Since the framework doesn't enforce it, we should ensure we have an architecture that structures our code. Our basis for consideration will be GRASP, or General Responsibility Assignment Software Patterns. It contains a set of 9 basic principles and responsibilities that we should apply in our code. For our purposes, let's select 4 responsibilities:

- **Information Expert** - the object with all the information needed to perform a certain task.
- **Controller** - the object that controls the flow of work.
- **Pure Fabrication** - the object that performs tasks that are not part of the domain.
- **Creator** - the object that creates other objects.

These 4 types of objects outline an obvious division that we can try to implement in our application:

- **Domain part**, which will represent the concepts of our client's business. We can also think of it as concepts that could exist without the IT system, e.g., instead of a product catalog, we have a flyer sent by mail to the customer's mailbox.
- **Technical part**, which is required to handle the domain part and exists solely for the IT system's needs.


First, we should identify the responsibilities above in our code and check if they are mixed together. This way, we will separate the technical part from the business logic, laying the foundation for further dividing our architecture into layers.


#### What Can Be Done?

The lack of enforced architecture often leads to a haphazard structure, resulting in code that is hard to maintain, untested, and challenging to develop. In the following article, we will look at what to pay attention to when creating an architecture: not to invent our own architectures from known templates, but to adapt them to our real needs and make the first architectural decisions.

large_blog_cover_high.jpg

medium_blog_cover_high.jpg

small_blog_cover_high.jpg

thumbnail_blog_cover_high.jpg

blog_cover_high.jpg

Backend Architecture on Frontend Part 1

#### What is a design system?

Whenever we're talking about a group of components e.g buttons, inputs, icons that share similarities in the design e.g colors, fonts - we're talking about a **design system**.

Whenever we're talking about font families line-heights, or font sizes for given headings and paragraphs (a.k.a typography) - we're talking about a **design system**.

To summarize, a design system is a set of guidelines and components that together create a coherent application. 


#### Advantages of a design system

1. **Consistency:** By introducing visual and interactive elements with a similar color scheme and fonts, a design system ensures that a given application looks and behaves consistently across a whole app or even multiple apps.
 
2. **Implement once, reuse everywhere**: It streamlines the design and development process by providing reusable components and patterns, reducing the need to reinvent solutions for common design challenges.
    
3.  **Scalability:** As applications evolve and new features are added, a design system helps maintain coherence and adapt to changes without compromising the overall user experience.


#### What makes a good implementation of a design system component?

Now that we know what a design system is and its benefits, let's consider for a second what we, front-end developers, need to keep in mind when implementing a component from the design system.

**Ease of use** - every component should have a simple and intuitive API that builds on top of or extends native HTML element attributes. Here are a couple of examples:
- every prop that corresponds to an event handler should start with the `on` prefix `onClick` `onInputChange` `onSelect` since it fits react elements event handlers `onClick` `onMouseEnter` `onMouseLeave`;
- every prop that is a boolean should be in the past participle form, e.g., `disabled`, `focused`, `selected`, since it fits  native HTML attributes, e.g buttons or inputs;

_**These rules are not set in stone and may differ from project to project. However, it's important to decide on one way, before implementation and document it as a guideline for other developers to be aware and follow.**_

**Extensibility** - there can be places within the application where the same component e.g. inputs, has a fixed width of 200px, but should take a full container width in other places. So,  each component should have some form of flexibility to also cover some out of ordinary scenarios.


####  Tools to implement a design system

At Bitnoise, we've designed and implemented many unique and beautiful design systems in React-based applications. Thus, we have a selection of proven tools that help us implement quickly and painlessly.

_**Keep in mind that this tool selection is mostly based on our team’s preferences. Selected tools may differ based on your project demands and team preferences.**_

These are the tools we commonly use:
- **[clsx](https://github.com/lukeed/clsx)** - for managing components classes.
- **[tailwind-merge](https://github.com/dcastil/tailwind-merge)**—to ensure that tailwind classes do not contradict one another.
- **[class-variance-authority](https://cva.style/docs)**—for handling complex component styling that differs based on provided props. For example, a button can have a primary, secondary, or ghost variant.
- **[react-aria-components](https://react-spectrum.adobe.com/react-aria/getting-started.html)** - to ensure our components are accessible and meet WCAG requirements.
- **[storybook](https://storybook.js.org/)** - for having all components list out and documented. It helps to avoid duplicated components and to introduce a new developer into a project.


#### Implementing a component

In this section I will guide you through my process of implementing the components from design systems.

##### 1. Looking at a provided design system

First things first, we need to examine the beautiful design system provided by a UI designer (for simplicity, let's focus on a single part of the design system - typography). 

![blog-heading.jpg](https://btnw-strapi-prod.dev.btndev.space/uploads/blog_heading_f729018df3.jpg)


Here are a couple of notes I took by looking at the design:
- we have 6 headings and 2 body texts,
- font sizes, font weights and line heights are as follows:
	- **Heading 1** - 92px, 700, 120%
	- **Heading 2** - 73px, 600, 120%
	- **Heading 3** - 59px, 600, 120%
	- **Heading 4** - 48px, 400, 120%
	- **Heading 5** - 38px, 400, 120% 
	- **Heading 6** - 30px, 400, 120%
	- **paragraph 1** - 24px, 400, 125%
	- **paragraph 2** - 16px, 400, 125%
	- **small text** - Manrope, 12px, 500, 125%


##### 2. Creating utils and utility types

Before implementing the component itself, we will add one utility function and one utility type that will help us in implementing this and other components. 

These utils help keep already long tailwind classes clean and noncontradictory to each other. 

_**If you're not using tailwind, you don't need to have this util... duh.**_

Similar to the built-in react utility type `PropsWithChildren` we're implementing a generic utility type `PropsWithClassName`  to ensure that our components will also accept the className prop and so that we don't need to add them manually in each and every component props.

##### 3. Implementing the component

Now it's time to get our hands dirty and actually start to implement the component itself.
-	Keeping in mind **ease of use** rule described above, we can map Heading 1, ..., Heading 6 to `h1` to `h6` html tags, which is convenient. Paragraphs 1 and 2 should be a `p` tag, and small text can be a `span`.


Now that the basis of the components were implemented, we should add styles for a given tag to match the design system. 


And then we can apply the styles to the component.

So far, so good, but what if we want to have a different color or we want to head 1 to be semibold instead of bold in some places in the application? The component should allow updating styles when needed.

Now overwriting basic styles is possible with new classes provided in the Parent component by using `className` prop. 

##### 4. Using the component in the application

Here's how it looks in the browser:

![blog-hello world.jpg](https://btnw-strapi-prod.dev.btndev.space/uploads/blog_hello_world_a7d7835f53.jpg)

#### **Whole component code:**


####  Summary

In this blog post, we've created a very intuitive and simple-to-use component that will handle typography in the application. If the styling of any given tag needs to be updated, it will only require a change in one place instead of looking for specific tags across multiple files.

I hope that walking you through my work process, from looking at a design system to implementing a React component will help you think differently about building components, ensuring they are both intuitive and highly reusable.


large_blog-MICHAŁ GĄSIOREK_cover_high.jpg

medium_blog-MICHAŁ GĄSIOREK_cover_high.jpg

small_blog-MICHAŁ GĄSIOREK_cover_high.jpg

thumbnail_blog-MICHAŁ GĄSIOREK_cover_high.jpg

blog-MICHAŁ GĄSIOREK_cover_high.jpg

Implementing a design system in React

In the previous article, we outlined the problem of lacking enforced architecture in frontend frameworks that also allow frontend developers to write backend code. In this article, we will look at what to pay attention to in order to start structuring your code at a low cost. However, before we delve into application architecture, it's worth making a few architectural decisions to shape our application.

#### Separating Queries from Commands

A common issue that causes code clutter and reduces maintainability is overly large objects. By "overly large," I mean objects that hold too much information simultaneously. The reason objects hold too much data is often due to read operations. Some data is needed to make decisions, while the rest is just to display to the user. It's beneficial to separate these two situations. Even if we store the data in a single database table, we should create two independent models: one for reading and another one for making decisions and updating.

To achieve this, we can apply the CQS (Command Query Separation) or CQRS (Command Query Responsibility Segregation) patterns in our code. They both assume the separation of reading (Query) from writing (Command). Queries never modify data, and Commands do not return data. The difference lies in implementation: in CQS, we might have a single service with Command and Query methods, while in CQRS, we have entirely separate services or even microservices for both types.

In the provided example, it might seem that not separating queries from commands generates less code. However, this is a very superficial conclusion. By using CQS/CQRS, we slim down our write models and can create more flexible queries for our read models. Adding additional read data does not affect our commands and tests, making them more resilient to changes. We also avoid multiple places for reading or writing the same model, making the code more reusable.
![blog-code 1.jpg](https://btnw-strapi-prod.dev.btndev.space/uploads/blog_code_1_a4980c7691.jpg)

_Code: Examples of CQS and CQRS. The repositories used are examples of Pure Fabrication from GRASP. They can also call Creator underneath, which instantiates returned objects._


#### Rich vs. Anemic Entities

Another important aspect is the approach to our data entities. Typically, there are two types:
- **Rich Entities** - contain both data and behaviors operating on that data. They do not have getters and setters. Behavior methods change the object's state and enforce business rules in one place. Rich entities are an excellent example of Information Expert.
- **Anemic Entities** - contain only data, along with getters and setters. Business logic is implemented in separate services that operate on these entities, change their state, and enforce business rules.

Existing backend frameworks often suggest the second approach, but using rich entities is a much better solution. Key behaviors, rules, and data are represented in one place, preventing entity bloat. In both cases, however, we should remember that entities should be as small as possible, containing only the data needed for specific decisions. A much better place for using anemic entities is DTOs (Data Transfer Objects), used for data transport between layers and modules, or objects for creating views (e.g., response from a Controller).

![blog-code 2.jpg](https://btnw-strapi-prod.dev.btndev.space/uploads/blog_code_2_2fea35e4d6.jpg)

_Code: Example of an anemic entity with a service handling it._

![blog-code 3.jpg](https://btnw-strapi-prod.dev.btndev.space/uploads/blog_code_3_e81ee58004.jpg)
_Code: Example of a rich entity with its use in a specific use case. AddOrderItemUseCase is an example of a Controller from GRASP._

#### Modules vs. Layers

Two techniques that help us divide our code into more manageable parts are modularization and layer division. An application module is more extensive and can be treated as a separate subprogram with its own application architecture (i.e., one that divides responsibilities according to layers) and its own API. Modularization is an individual, more significant topic, so we'll focus only on application architecture in this article. The following article will consider the two most popular application architectures: three-layer architecture and clean architecture. Regardless of the architecture type, it's important to remember that layers always have a unidirectional relationship, meaning the lower layer knows about the higher layer, but the higher does not know about the lower. This is crucial to avoid creating spaghetti code. Remember, the difference between a mere directory structure and layers primarily lies in respecting their relationship boundaries.

#### Did I Define the Layer Boundaries Correctly?

A good question is whether the boundaries I defined between layers are indeed boundaries. To this end, it's worth conducting a thought experiment. If I remove the lower layer and instead insert tests that call my layer, will the code of my layer still perform its tasks? If not, and there are missing dependencies to the lower layer, it means the boundary between layers is not respected, and our code will slowly degrade. Another more technical method is to use a simple architectural test that checks if there are imports to the lower layer's directory within the files of a given directory.

#### Application Architecture

Identifying and assigning responsibilities to objects in our code and determining the approach to our read and write entities is the basis for adequately dividing it into layers. In the next part, we will present the types of application architecture and how they interact with the concepts presented in this article. We will also identify the essential responsibilities of GRASP within the individual layers of known architectures.


Backend Architecture on Frontend Part 3

Łukasz

What do best React.js teams have in common?

Piotr

How do mid and senior React.js developers cooperate at Bitnoise?

Adam

The server-first future of React – guide for CTOs

Jan

Decoding React UI: Unveiling the Best Component Libraries in a Head-to-Head Showdown!

Wioletta

Developer is sweaty, TypeScript spaghetti

Michał

Git Gut: Take care of your commits history like a pro

Michał

Backend Architecture on Frontend Part 1

Łukasz

Implementing a design system in React

Michał

Backend Architecture on Frontend Part 2

Łukasz

Boom! How we built a pixel-perfect frontend for a SuperSonic company

Grzegorz

PozTechTalks #03: News on the frontend

Magdalena

PozTechTalks #04: How we recruit for frontend positions

Magdalena

GET IN TOUCH