1

I work with some not-monolithic applications, meaning that at some level, it depends on other applications to do the work. At the moment, each application on our stack, when there is an API change, generates a new API SDK, that can be used by other applications that rely on it. The issue is that this adds an explicit dependency and another thing to maintain, since the API needs to be generated.

I read that our current approach should be avoided when building microservices and that's our main goal. The other approach is to have a well defined API and the services that rely on it should handle the API integration by themselves. But if more than one application has to build it's integration layer, code gets duplicated across applications and it's also time consuming when the team could be building features.

What's the best approach when working in such environment?

Edit 1: The main concern is that every API change requires the API SDK to be generated (we do that with Swagger) and published to our internal maven repository). I wonder if there is more transparent way of doing that.

  • 2
    can you add some detail to the problem you are experiencing? obvs if you have a dependency on an api then you have a dependency on an api – Ewan Jul 31 at 14:04
2

It's hard to get around the fact that if two programs talk to each other they have to agree on the message format.

Not every change to and API requires a client change though. I normally separate out publishing the MicroService from publishing its client library.

That way if you fix a bug and have interface changes in a version, you can update the server without updating the client.

The post you read : https://codeburst.io/so-there-are-two-paths-to-be-considered-here-1d1aef6007e9

Is simply wrong. Services depend on your microservice and have a client for it whether or not you wrote and publish that client. If you update the service, the code calling it doesn't magically update just because you haven't provided a library

Sure you should document the api and enable others to write clients for it if required. But where you use your own services its just common sense to write the client once and consume it as a library in all your dependent projects.

The alternative is writing the same client in every project.

Some people make the argument for partial clients, where dependent projects write their own client but only implement the parts of the api they use.

I'm sure you can see that this end up being the same thing once you hit any sort of scale and the overlap between clients increases.

  • 1
    that's what we usually do when the changes are backward compatible. – luizfzs Jul 31 at 14:30
  • so, what your issue with publishing the api client? "I read that our current approach should be avoided" where? – Ewan Jul 31 at 14:32
  • on this post: codeburst.io/… – luizfzs Jul 31 at 14:36
0

Versioning your sdks. You need a versioning strategy in place to avoid disruption/downtime. Here's a good lead on how ING managed their versioning, there's a youtube presentation of this talk as well.

https://www.slideshare.net/PatriceKrakow/api-versioning-for-zero-downtime-devoxx-belgium-2017

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.