0

Use-case:

As part of an Airline Application I am building - I am developing a set of (RESTful) API's each for Flights, Lounges, Loyalty etc. There are some common methods which should be accessible from all the API's.

Current Implementation:

At present, we have deployed these as separate war files on our Tomcat servers. We have developed them using Java\Spring - and we are using a common ApplicationConfiguration and a WebInitializer file's from which others inherit. Basically it is split into the packages Common, Flights, Lounges and Loyalty and each of them has 1 or more API's within itself. Is this the right approach?

During the course of last one year - we have added multiple versions to each of the API's, all of which are deployed on a single tomcat instance. Is this advisable?

More importantly, is this the right approach? From the very little I have heard about Micro-services - is this the right approach in scenarios like this? How else would you suggest implementing them. I am developing a similar set of API's for a different application and would like to have the right approach for it.

  • From the very little I have heard about Micro-services - is this the right approach in scenarios like this? 1. Haven't you heard enough and you already thrown yourself to the wild? You are so brave :-). 2. We can't answer this question because you have not exposed the company needs that made you choose this sort of architectectural style. The best answer you will get here is... Keep reading about Microservices. Looks like you are missing too many things. A good answer may fill a book like the one I'm still reading (endless book). – Laiv Jul 1 '17 at 9:46
1

I have for each microservice one gradle Project. So that each microservice can be simple deployed as self contained application.

I also have set up a gradle project with a name like "microservice-core". It is a shared library with common classes that are needed for every microservice. So that other micro services can easy pull them from a maven repository. It contains only structure elements like Data Transfer Objects. So I don't have to create an refactor it in every microservice when requirements change.

I would recommend to use a container service like docker to run your microservices and setup a Continuous delivery Pipeline(jenkins). Without one it's a mass of stupid work to build, test, update and deploy microservices.

I think it is ok if you have several API's of subdomains in one microservice if the parent domain is the same. Like an accountservice with build in Authorizationservice!

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.