What needs improvement with IBM API Connect?

The only downside where improvements are needed is probably on the licensing side. Scalability is an issue with IBM API Connect, making it an area where improvements are required.

We have encountered challenges with IBM API Connect, particularly during significant upgrades. These upgrades demand substantial labour and financial resources, including consulting services from IBM. I'd like to see increased flexibility, more frequent updates with new features, an efficient upgrade process, and additional AI capabilities for future releases.

The platform’s integration with the payment gateway needs enhancement. The setup process and support services could be improved.

It would be nice to have a SaaS solution that can be deployed into the cloud.

The administration of the user interface and the technical documentation are areas of concern in the solution where improvements are required. The solution's technical documentation should be a little bit easier to understand, and it is a traditional problem with all IBM products. The technical documentation is a bit too difficult to understand, and it is also not easy to read.

Understanding the architecture, deployment criteria, and communication methods of the installation can be time-consuming. The learning curve is noticeable, especially for new engineers.

There is room for improvement regarding the connectivity of the DevOps.

The only disadvantage I can see is that it requires heavy hardware support, which can be considered quite expensive. In terms of new functionality, I think the analytics can be improved in V10. The analytics feature was better in the older version, 2.18. But in V10, it's not as flexible. When exporting analytics as KSP or JSON, it's not well formatted. They can work on enhancing the analytics part. Additionally, they can focus on reducing the hardware cost.

There are two disadvantages to the solution. Firstly, the pricing model, when compared to other open sources, is high. Secondly, the availability of resources in the market, specifically the developers available in the market, is not so much. So, the aforementioned areas need to be considered for improvement.

The implementation process could benefit from improvements, as it may take some time to become accustomed to the deployment.

I am currently investigating the weaknesses of the solution, specifically in its on-premise infrastructure. One of the main concerns is its performance, as we have noticed some cases of resource consumption that may be related to our setup. We have concerns regarding the handling of asynchronous APIs and events in the architecture, particularly in the financial sector, where this is becoming more common. While this is well-addressed in MuleSoft, we are uncertain about how IBM API Connect handles this use case, as it does not appear to be addressed in the available documentation.

Improving the documentation would be beneficial as it currently presents navigation challenges. Incorporating a step-by-step guide could facilitate the integration or migration of various systems, including databases. The existing documentation only comprises plain text, hence incorporating more interactive instructions could enhance its usefulness.

It's based on a little bit dated architecture. A lot of evolution has happened after that. It's an evolving field. Kong is a Kubernetes-based platform. Kong runs on Kubernetes, but all the other ones are in microservices. So, there's a lot of improvement that can be done.

One issue we have with this solution is its complexity. In addition, it doesn't handle large volumes of traffic very well.

Technically, I haven't faced any issues or areas for improvement in IBM API Connect. There wasn't any concern that the customer asked that we couldn't resolve or achieve. I'll need to check with the technical team if there was any issue with the solution, but from the top of my head, I haven't faced anything that the customer requested or anything that needs enhancement in IBM API Connect. The implementation of IBM API Connect is complex, as it's an enterprise solution with many components that require more than one person. It's not a single product that you work on, and this is an area for improvement, but normally, it's good. Having a more structured model for IBM API Connect support is also room for improvement that would help customers better.

The monetization of the API could be improved. The pricing for the consumer is also very important to improve this solution. Nowadays, we are sending information to other tool in order to process out of API Connect. They could improve this internal service in order to have the balance for the consumer's API for different companies, external to our company.

IBM API Connect could improve the security of the application and the integration.

The integration of cloud-based services is where we're looking for improvement in this platform.

The developer portal could be easier to customize - as it's Drupal-based, I have to hire a Drupal developer to do it for me. I feel there should be a drag-and-drop or UI-based configuration to customize the developer portal. In the next release, I would like some support for file uploads and MQ integration.

Installation is weak. We (three people) ran into so many problems that I would, as an engineering manager, give this back to the development team. Too many secrets (even if they are set by default, we had problems). The big footprint of pods, a complex network of them. This should be simplified. To me, the product looks over-engineered. On the other hand, documentation needs more examples, this is "under-engineered". They need to provide debugging facility for service implementations and policies (see gravitee.io for an example)

Documentation for the CLI is not very complete. Also, the support could be improved, and we have had several problems with backing up and restoring the product.

Having more integration and compatibility with different platforms is what I'm expecting in the next release of IBM API Connect. The issues with this solution are mainly around support. Recently, people were discovering that WSO2 is commercializing it, because initially it was just open source. Right now, because they are commercializing it, the intro licenses are as costly as IBM. People say: "IBM is tried and tested", so it's people who know this who'll go the IBM API Connect route. Other people who just want to try out a more scalable solution, on the other hand, will go the open source route. Others will either just do the cloud version, because everything is less maintenance, while other people prefer doing everything themselves, e.g. in-house, from scratch. IBM API Connect should offer more versatility to its users, because they only give you a specific level of the versatility, and this is something IBM should heavily invest on.

The solution could improve security and performance.

IBM API Connect could be improved with better monetization and customization capabilities. I work for a Saudi Arabian client and we use Stripe as our payment gateway, but Stripe doesn't have a gateway in Saudi. This means that our monetization capabilities are limited. We are also not happy with the portal experience. The API developer portal isn't attractive. We want something eye-catching, but this isn't easy to do because the customization possibilities are so limited. Our main pain points are in these two areas: creating a better developer portal and improving stability in terms of synchronization and monetization.

One thing about API Connect that could be improved is the security schemes. There are so many security schemes, and from a product perspective, IBM could improve the user experience of the configuration security scheme. It does what it is supposed to do, but it could be easier to configure. The junior developers sometimes find it a bit confusing to configure even though they understand the concept. And another thing is that I don't know the security policies that we have. For instance, we have a service account, which is needed to connect to some other services. So in those cases, I find it a bit hard to tweak things in the API gateway. And one could argue that it is not the right thing to do with the API gateway. It has a different place to be, which could be why they haven't put it there. But sometimes, you have to tweak around that, and I find it a little bit hard to do that. So if they could accommodate that in there, it would be better for some people.

It should be cheaper.

Debugging could be improved, the solution doesn't really give a lot of debugging, and I'd also like to see an improvement in the analysis.

There are certain areas that need improvement. The first one is the design time setup. It has a lot of customizable fields, but we need certain standard fields to be added, such as what all of the consuming systems are. This needs to be very clearly articulated during the design time. The second, which was a very big issue for me for adoption, is that they don't give any out-of-the-box solutions for knowing how many users have logged on during the design time and who has access to the portal for how much time. There is no capability right now to tell me the usage details and user rights. As for additional features, design time user analytics would be great to have in the next release.

The documentation needs to be a bit better. It's very sequential, however, I don't understand what options to choose for certain tasks. I need to read all of the documentation to find what I need. It's easier to look at recommendations or to watch Youtube videos that show specific examples. There needs to be more in the toolkit to complement the product. We could have more features, for example, for queries to the platform.

The solution would be better if it had cloud functionalities. It would be very helpful if it supported Azure and/or AWS marketplaces. Right now, if I want to set up something in Azure, I need to set up a VM from scratch instead of just being able to have it be supported and integrated.

We've had some issues upgrading to the latest version of the solution. The documentation could be improved. When we download a fix that was expected to be seamless to install, it wasn't. In the past, it was easy just to go to any product and download the documentation. If you had the license, you download the product, install it, look at the documentation. Only for specific cases would you have to reach out to support. Now it is like we know that, for these products, we're going to have to call or engage at some point with support. It's painful right now. It's not a smooth installation. A hybrid cloud enablement would be very useful. We tried to stand up a gateway in IKS and we were told by support that that was not possible. Yet, the technical people, the designers of the solution, started saying, no, you can actually do it. However, they never said is supported, so I was never sure where the solution stands on hybrid clouds. The answers that sometimes are provided are not very comforting. If it isn't a full commitment it isn't going to work. They need to make it a product that can be downloadable and installable and workable without having to engage with them directly.

The automation and the simplicity could be improved. They could also have more frequent additions. I would like to see the simplicity improved to make it very easy to deploy and to make it very easy for the regular developer, not an API special developer. I would like the developers to be able to develop APIs and to make them more accessible. I would also like to have a DevOps built-in process that is very fast and easy. The monitoring suite should be ready-made and not have to tailor-make my home.

The initial setup and installation could be easier. The price could also be better. I would like to see monetization of support, a monetization billing engine, and monetization within the product in the next release.

The developmental process is not quite user-friendly. IBM should improve the customization of the API Connect. The price could be reduced, it's expensive.

Improvements depend on your perspective and what you need the API to do. I think it has room for improvement because, for example, there's nothing to show that other teams might be dumping the same thing and you have no way of knowing if it's redundant. I feel that sometimes different versions of the same thing are put in there. Although there may be slight differences like including some extra fields, at the end of the day, you're almost dumping the same API again into API Connect. At some point the product should be able to tell you that there is already a similar API there and whether you're dumping an API that's almost identical to what is there.

One place that I think the product could improve is that it could be lighter on computing resources and cheaper. We did not expect to have to add additional services for data processing.

It would be helpful to have access monitoring. The initial setup is complex.

The product can be improved in the following areas: 1. The monetization because it doesn't include an online method to pay through a web system or with a credit card, where the analytics can be calculated. 2. The integration of an API gateway that implements the sidecar pattern, which can be deployed in cloud applications, and expose the microservices directly in each pod, this can be more decentralized components. All of these areas can be improved.

In terms of what needs improvement, some of the product documentation could be better.

Extracting the data could be improved. My team members sometimes find it difficult to get something out of this solution.

There is room for improvement in the reporting and monetization. With monetization, I want to be able to provide my own pricing and platform. I would like them to add hooks into the API. E.g., it should be able to check credit, then limit access to people who don't have credit anymore. They need to have more training for people.

I would like to see support for non-Java based services. We struggle a bit to be able to deploy and connect our .NET services because of things like data types. We had to map a couple of things. For one solution provider, we had to move them to .NET Core before we could use it properly. I would like to see more agnostic tool service platforms rather than moving it more towards Java or open source.

They seem to have left out a feature for microservices and also a certification module for OIDC. So it would be a good idea for the authentication module to have OIDC certification.

It still does not support open API 3. Another problem is the designer. I want the whole solution to be on the cloud. For the installation, I have to install locally. There are many improvements it needs if I want to implement a MockServer or sandbox. In the future, I hope it will be more intuitive for building a MockServer. In the next version, I don't know if they've already been included it or not, but the designer and all the tools should be on the cloud. I don't want any external installation or local installation. The old designer should be less complex and more simple or intuitive for you to search as well.

It is still a very new product. We're still finding our feet on the latest version of it because it gives you the capability to move into the cloud. We have not yet taken that leap into cloud because of the uncertainty of what the moving parts are, and that's why we'll have to wait and see. I would like to see more stability, however, and I do believe the newer version will offer that.

IBM is also a bit pricey. On top of that, they have bugs that need to be fixed.

Like any typical IBM infrastructure setup, you need to learn to set it up yourself. It's not one of those simple zip files or an archive unzip and you're up and running in some few minutes. Knowledge to set it up is key. A more user-friendly portal could be helpful. Something you won't really get lost in. For example, other APIs make it so easy to do a couple of things from the portal, not at the management portal itself. Maybe if IBM can improve on that, it would be most helpful.

Business applications could be exposed to users.

Automation for our Domino applications could be improved.