3

There are lots of good resources on μServices that focus on concepts like Single Purpose, REST, Implementation and Deployment, CI/CD, Encapsulation and Isolation, Separating UI from API, etc.

However, having made all the promises about μServices (plural), they all immediately go deep into designing a μService (singular). Or, if I can be snarky, "Writing Tiny Software Monoliths."

Where are the best practices for using μServices with μServices?

Example:

Say my company tells me to write an internal Craigslist clone for selling unwanted christmas gifts to co-workers. The Resources are fairly self-evident: Person, Location, Item. Only Item is fully within the scope of this μService, so I start focusing on the REST operations for that:

GET /v1/items/7443fc08-51c3-11e6-9c77-3c15c2c9fbf8

{ "title": "Book for Sale",
  "body":  "Selling my well-used copy of 'Functional Programming with Cobol'",
  "price": "$10 OBO",
  "contact": {
    "type": "ref",
    "ref":  "ldaps://ad.example.com/eid=51214,dc=example,dc=com"
  },
  "location": {
     "type": "ref",
     "ref": "https://facilities.example.com/v1/locations/3182"
  }
}

Everyone reviews that and says "Yes, that's tasty and RESTy," so we go forward. The UI developer needs some hand-holding because she's never dealt with LDAP before. When I tell her to "Just add '?cn' to the end of the URL to get the person's name", she asks why I didn't just put that into the URL in the first place, or at least provide a links[] block with a "rel" field.?

I explain it's just field selection, exactly like ?include= selection, say nobody uses rel for field selection, and send her home with a copy of RFC 4512, telling her that learning ASN.1 will make her a better developer.

Fast forward several days; I'm done the API, but while the UI can display items and lists of items, it's just showing factory data; the POST functionality isn't working yet...

The UI developer is still trying to figure out how to get the eid value (for the LDAP URI) from the OAuth token she received from the federated login μService. We discuss creating another μService just to do that...


So where did it go wrong? What are the current best practices on balancing the principle of "Single Responsibility" outside the context of only a Single μService?

1 Answer 1

1

One place where current best practices are discussed in depth is the book Building Microservices published by O'Reilly. It's a big topic, and the author goes into detail about how to define the size of the domain to be covered by the service.

On foreign references specifically, the author leans towards not enforcing referential integrity between services. So your Service A might refer to a userId that's provided by your federated login service, but without referential integrity on that value stored in the database of Service A.

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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