Your Web News in One Place

Help Webnuz

Referal links:

Sign up for GreenGeeks web hosting
February 12, 2024 10:36 am GMT

Implementing a Service Oriented Architecture in 2024

The advantages of microservices can generally be categorized into two groups: technological and human-centric. Within the human-centric category, the benefits relate to how we work and collaborate.

Teams working on microservices have full ownership over parts of the system. They can work independently, choose their own stack, and deploy their services independently and in parallel to other teams.

In addition to that, although microservices as a system can become more complex, individual services are simpler and easier to understand and maintain.

This sort of reverse Conways Law, where the systems architecture influences the organizational structure, is a key benefit of microservices that can also be found in other types of distributed systems.

How can we make our system more distributed and composable to get more of the same benefits?

In this article, well look at Bit as a tool that allows us to compose systems from independent components of all levels of granularity, from simple utility functions to microservices and, ultimately, to entire systems.

Bit: A next-generation build system for composable software.

Well see how Bit components can be shared and reused across microservices, how microservices can be maintained as Bit components, and how they can be composed in runtime using an API gateway component.

Building a composable system

To better understand how Bit can be used to compose microservices, lets start by creating a new workspace with a few Bit components:

bit new react my-project --env bitdev.react/react-env --default-scope my-org.my-project
cd my-project

Your new workspace has seven components. Run bit start to explore your components using Bits UI:

Image description

To run the system, run:

bit run my-project

The output should list several different processes listening on different ports. Two microservices, discussion-server and user-server, an API gateway, and a frontend application:

[discussions-server]: running on port 5003[user-server]: running on port 5002[HPM] Proxy created: /  -> http://localhost:5002/graphql[HPM] Proxy rewrite rule created: "/user-server/" ~> "/"[HPM] Proxy created: /  -> http://localhost:5003/graphql[HPM] Proxy rewrite rule created: "/discussions-server/" ~> "/"backend server running on 5001frontend server running on 3001 

This runtime composition of different services, both locally and remotely, is done using the platform component. It is another Bit component whose role is to serve as the entry point for this system:

import { Platform } from '@bitdev/platforms.platform';const UserServer = import.meta.resolve('@bitdev/node.examples.user-server');const DiscussionServer = import.meta.resolve('@my-org/discussions.discussions-server');const AcmeWeb = import.meta.resolve('@my-org/my-project.my-platform-project-web');const PlatformGateway = import.meta.resolve('@bitdev/symphony.backends.gateway-server');export const MyPlatformProjectPlatform = Platform.from({  name: 'my-platform-project-platform',  frontends: {    /** main frontend application for the platform */    main: AcmeWeb,  },  backends: {    /**     * use an api gateway component.     * supports proxy of graphql and restful requests.     */    main: PlatformGateway,    services: [      /** compose micro-service components. */      UserServer,      DiscussionServer    ]  },});

Note that not all Bit components need to be maintained locally. A composition of services can include remote services that are not available locally. This is tremendously helpful for local and remote testing of services in the context of the entire system.

To learn more, see the Platforms documentation.

Also, note that the API Gateway can be implemented in whatever way suits your needs. To explore the one used by this example, see:

Image description

Build-time or runtime integration? The choice is yours!

One thing that is immediately apparent when reviewing the Bit components in your workspace is just how different they can be. UI and non-UI, Node and React, small and large.

However, in the context of this article, the most important distinction is whether they are app components or not. App components are components that are available for consumption as Node packages, just like regular Bit components, but are also deployable and available for runtime compositions.

For example, our discussion-server Bit component runs as a separate process. Looking at its implementation, we can find one file that sets it apart from other components: the .bit-app.ts file.

/** @filename: discussion-server.bit-app.ts */import { NodeApp } from '@bitdev/node.node-app';export default NodeApp.from({  name: 'discussions-server',  artifactName: 'discussion-service',  mainPath: import.meta.resolve('./discussions-server.app-root.js'),  /**    * an optional deploy function for this app component -   * to be executed when a new version of this compoennt is released   */  // deploy: () => {}});

With Bit components, youre always building and delivering independently.

You can enjoy the benefits of a composable and distributable system, regardless of how (and when) components are being integrated. This gives you the freedom to construct a system that perfectly balances your human or organizational needs with technological requirements.

For example, you might want more than one team to maintain different aspects of a microservice. You can split the microservice into several microservices, but thats not always the best solution when taking into consideration your systems performance. It might be that build-time integration of independently delivered Bit componetns is a better choice.

A symmetry between dependencies in dev and prod

One benefit of this style of composition of Bit components is that it provides you with a clear dependency graph that includes components composed in runtime. This can be tremendously helpful in understanding complex systems and in maintaining them.

Image description

As mentioned earlier, with Bit your systems composition is a hybrid of services integrated in runtime and packages integrated in build time. Zooming out a bit further will reveal some of the Bit components used to compose this services:

Image description

Reusing Bit components: faster development and better standardization

Bit components can be maintained, released, and installed from any project. That makes them an excellent tool for reusing code and standardizing the development process across separate projects.

The discussion entity component as an example

Image description

For example, your workspace has an entity component called discussion. The discussion component provides the data modeling and a set of operations that can be utilized by any microservice or frontend application that handles discussion data within your system.

It is a contract between services that outlines the structure and rules of engagement for discussions, ensuring consistency and reducing the duplication of effort when developing new features that interact with discussions.

Furthermore, by using Bits versioning system, developers can easily upgrade to new versions of the discussion component as it evolves while maintaining compatibility across the services that depend on it.


Original Link: https://dev.to/giteden/implementing-a-service-oriented-architecture-in-2024-56mn

Share this article:    Share on Facebook
View Full Article

Dev To

An online community for sharing and discovering great ideas, having debates, and making friends

More About this Source Visit Dev To