CODEWITHSUNDEEP
microservices
Oreborous
Oreborous

Reputation: 332

Microservice requests

I'm trying to start a little microservice application, but I'm a little bit stuck on some technicalities.

I'm trying to build an issue tracker application as an example.

It has 2 database tables, issues and comments. These will also be separate microservices, for the sake of the example.

It has to be a separate API that can be consumed by multiple types of clients e.g. mobile, web etc..

When using a monolitic approach, all the codebase is coupled together, and when making a request to let's say the REST API, I would handle for example the '/issues/19' request to fetch the issue with the id '19' and it's corresponding comments by means of the following pseudocode.

on_request_issue(id) # handler for the route '/issues/<id>'
    issue = IssuesModel.findById(id)
    issue.comments = CommentsModel.findByIssueId(id)
    return issue

But I'm not sure on how I should approach this with microservices. Let's say that we have microservice-issues and microservice-comments.

I could either let the client send a request to both '/issues/19' and '/comments/byissueid/19'. But that doesn't work nice in my point of view, since if we're having multiple things we're sending alot of requests for one page.

I could also make a request to the microservice-issues and in that one also make a request to the microservice-comments, but that looks even worse to me than the above, since from what I've read microservices should not be coupled, and this couples them pretty hard.

So then I read about API gateways, that they could/should receive a request and fan out to the other microservices but then I couldn't really figure out how to use an API gateway. Should I write code in there for example to catch the '/issues/19' request, then fan out to both the microservice-issues and microservice-commetns, assemble the stuff and return it? In that case, I'm feeling I'm doing the work double, won't the API gateway become a new monolith then?

Thank you for your time

Upvotes: 1

Views: 583

Answers (2)

Arnon Rotem-Gal-Oz
Arnon Rotem-Gal-Oz

Reputation: 25909

One of the motivations for breaking something to small(er) services is service autonomy, in this case the question is, when the comments service is down should you display the issue or not- if they are always coupled anyway, they probably shouldn't reside in two services, if they aren't then making two calls will let you get this decoupling

That said, you may still need an API Gateway to solve CORS issues with your client

Lastly, comments/byissueid is not a good REST interface the issueId should be a parameter /comments/?issueId=..

Upvotes: 1

Yarix
Yarix

Reputation: 1301

API gateway sounds like what you need. If you'll keep it simple, just to trigger internal API, it will not become your new monolith.

It will allow you do even better processing when your application grows with new microservices, or when you have to support different clients (browser, mobile apps, watch, IOT, etc)

BTW, the example you show sounds like a good exercise, in reality, for most webapps, it looks like over design. I would not break every DB call to its own microservices.

Upvotes: 1

Related Questions