Why ABP.IO Platform?

THE PROBLEM

Which libraries should you use to implement common requirements? The software development ecosystem is highly dynamic, making it challenging to keep up with the latest tools, libraries, trends, and approaches.

THE PROBLEM

When addressing UI concerns, a range of challenges surfaces. These include establishing the groundwork for a responsive, contemporary, and adaptable UI kit with a consistent appearance and a host of features like navigation menus, headers, toolbars, footers, widgets, and more.

Even if you opt for a pre-designed theme, seamlessly integrating it into your project could demand days of development. An additional hurdle lies in upgrading such themes. Frequently, the theme's HTML/CSS structure becomes intertwined with your UI code, rendering future theme changes or upgrades intricate tasks. This interweaving of code and design complicates the flexibility of making adjustments down the line.

THE PROBLEM

Establishing a robust testing environment is a time-consuming endeavor. It involves setting up dedicated test projects within your solution, carefully selecting the necessary tools, creating service and database mocks, crafting essential base classes and utility services to minimize redundant code across tests, and addressing various related tasks.

THE PROBLEM

After you've set up the solution for development, you usually have to teach the developers how the system works and how to build it using the same agreed-upon methods. Even if you give them training, keeping the documentation up-to-date can be difficult. As time goes on, each developer might write code in their own way, causing the rules for writing code to become different from each other.

THE PROBLEM

After you start your development, you must keep track of the new versions of the libraries you use for upgrades & patches.

THE PROBLEM

Single Sign On, Active Directory / LDAP Integration, OpenIddict integration, social logins, two-factor authentication, forgot/reset password, email activation, new user registration, password complexity control, locking account on failed attempts, showing failed login attempts... etc. We know that all these generic requirements are familiar to you. You are not alone!

THE PROBLEM

Cross-Cutting Concerns are the fundamental repeating logic that should be implemented for each use case. Some examples;

• Starting transactions, committing on success and rollback on errors.
• Handling and reporting exceptions, returning a proper error response to the clients and handling error cases on the client side.
• Implementing authorization and validation, returning proper responses and handling these on the client side.

THE PROBLEM

You typically need to build infrastructure to implement your architecture properly. For example, you generally implement the Repository pattern. You define some base classes to simplify and standardize to create entities, services, controllers and other objects.

THE PROBLEM

There are a lot of requirements you repeatedly implement in every business application;

• Detailed permission system and managing permissions on the UI based on roles and users.
• Writing audit logs and entity histories to track when a user modifies a database record.
• Make your entities soft delete, so they are marked as deleted instead of physically deleting from the database and automatically filtering deleted entities on your queries.
• Creating abstractions and wrappers to consume your backend APIs from the frontend code.
• Enqueuing and executing background jobs.
• Handling multiple time zones in a global system.
• Sharing validation, localization, authorization logic between server and client.

THE PROBLEM

You will build many similar pages in a typical web application. Most of them will perform similar CRUD operations. It is very tedious and also error-prone to repeatedly create such pages.

THE PROBLEM

Most libraries are designed as low level, and you typically do some work to integrate them properly without repeating the same integration and configuration code everywhere in your solution. For example, assume you must use RabbitMQ to implement your distributed event bus. All you want to do is; send a message to a queue and handle the incoming messages. But you need to understand messaging patterns, queues and exchange details. To write efficient code, you must create a pool to manage connections, clients and channels. You also must deal with exceptions, ACK messages, re-connecting to RabbitMQ on failures and more.

THE PROBLEM

All the infrastructure, even in the simplest way, takes a lot of time to build, maintain and document. It gets bigger over time, and it becomes hard to maintain it in your solution. Separating these into a re-usable project is the starting point for building your own internal framework.

Building, documenting, training and maintaining an internal framework is really hard. If you don't have an experienced, dedicated framework team, your internal framework rapidly becomes an undocumented legacy code that no one can understand and maintain anymore. On the other hand, these frameworks are generally developed by one or two developers in the team. And these fellows are becoming a knowledge silo. It is good for them but bad for the company because they are the project's single point of failure -SPOF-. Once they leave the company, the project dramatically goes down.

THE PROBLEM

Multi-Tenancy is a common way to implement SaaS systems. However, implementing a consistent multi-tenant infrastructure may become complicated.

THE PROBLEM

Building a microservice system requires many infrastructure details: Authenticating and authorizing applications and microservices and implementing asynchronous messaging and synchronous (Rest/GRPC) communication patterns between microservices are the most fundamental issues.