3

I have a question concerning microservices and databases. I am developing an application: a user sees a list of countries and can click through it so he can see a list of attractions of that country. I created a country-service, auth-service (contains users for oAuth2) and an attraction-service. Each service has its own database. I mapped the association between an attraction and its country by the iso code (for example: BE = belgium): /api/attraction/be.

The approach above seems to work but I am a bit stuck with the following: a user must be able to add an attraction to his/her list of favorites, but I do not see how that's possible since I have so many different databases.

Do I create a favorite-service, do I pass id's (I don't think I should do this), what kind of business key can I create, how do I associate the data in a correct way...?

Thanks in advance!

Jdruwe
  • 3,450
  • 6
  • 36
  • 57

2 Answers2

3

From the information you have provided, using a standalone favourite service sounds like the right option.

A secondary simpler and quicker option might be to also to handle this on your user service which looks after the persistence of your users data as favourites are exclusive to a user entity.

As for ID's, I haven't seen many reasons as to why this might be a bad idea? Your individual services are going need to store some identifying value for related data and the main issue here I feel is just keeping this ID field consistent across your different services. What you choose just needs to be reliable and predictable to keep things easy and simple as your system grows.

Ian Belcher
  • 5,583
  • 2
  • 34
  • 43
  • I was thinking that id's might be bad because that although they should not change they might change, for example migration to another db... – Jdruwe Jul 03 '16 at 10:06
  • Yeah, that's a really good point. I guess it's a case of managing the extra work compared to the risk of that occurring. – Ian Belcher Jul 03 '16 at 10:20
  • The thing is, If I store it in a favorite specific db, how would I reference the user without specifying a user id? Maybe a username? – Jdruwe Jul 03 '16 at 10:29
  • At the same time, as long as your service's API is agnostic to the database being used which it obviously should, migration issues such as this could be handled during migration by implementing a secondary unique key if required which would allow you to keep using the original key which is stored in your other services. – Ian Belcher Jul 03 '16 at 10:36
  • And yeah, you'd need to store the user ID or some other static reference to the user. Your favourite service would be synonymous with a many to many lookup table in a RBMS. – Ian Belcher Jul 03 '16 at 10:38
  • As for IDs, you can use a GUID created by the client and attach that GUID to your state changing operations, this way you have now issues referencing an identity across your microservices, makes sense? – Sean Farmar Jul 03 '16 at 18:00
  • Agreed with the use of GUID's, but their creation should be the responsibility of the owning service, not the customer / client. You may have multiple customers of your service (importing service or an edge API service for example) which shouldn't be concerned with GUID creation. – Ian Belcher Jul 03 '16 at 22:50
  • So when I create an entity (for example country) I should also persist a GUID for this entity? – Jdruwe Jul 28 '16 at 19:08
1

If you are using RESTful HTTP, you already have a persistent, bookmarkable identification of resources, URLs (URIs, IRIs if you want to be pedantic). Those are the IDs that you can use to refer to some entity in another microservice.

There is no need to introduce another layer of IDs, be it country codes, or database ids. Those things are internal to your microservice anyway and should be transparent for all clients, including other microservices.

To be clear, I'm saying, you can store the URI to the country in the attractions service. That URI should not change anyway (although you might want to prepare to change it if you receive permanent redirects), and you have to recall that URI anyway, to be able to include it in the attraction representation.

You don't really need any "business key" for favorites either, other than the URI of the attraction. You can bookmark that URI, just as you would in a browser.

I would imagine if there is an auth-service, there are URIs also for identifying individual users. So in a "favorites" service, you could simply link the User URI with Attraction URIs.

Robert Bräutigam
  • 7,514
  • 1
  • 20
  • 38
  • I am not really sure what you mean, can you give an example please? – Jdruwe Jul 07 '16 at 18:28
  • I mean the "key" of a user is `http://auth.mycompany.com/user/123`, and an attraction is `http://attraction.mycompany.com/attraction/654`. In a "favorites" service you can simply associate these two strings, that way you don't have to depend on anything internal to these objects. – Robert Bräutigam Jul 08 '16 at 05:52
  • But aren't the 123 and 654 internal db id's? – Jdruwe Jul 08 '16 at 11:48
  • Could be. It doesn't matter, since the client does not really see "123" as a separate entity (it doesn't know how to parse the URI). It only sees a URI as a complete whole. It could be `http://attraction.mycompany.com/feda653dffgjknwe` and wouldn't make any difference to the client in terms of knowledge. The point is the cool URIs don't change (http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-732). It doesn't really matter what is in the URI as long as this property holds. – Robert Bräutigam Jul 08 '16 at 11:55
  • So this could be ok /api/attractions/BE ? – Jdruwe Jul 08 '16 at 12:01
  • Well, sort of. Why make it so complicated? Why do you include the country (name not unique perhaps?), and a hash of the name? Also, the name can change, so the URI will potentially also change with it, which is not what we want, since the 'favorites' service might store the URI. – Robert Bräutigam Jul 08 '16 at 12:06
  • So you say that I should just use a db ID? – Jdruwe Jul 08 '16 at 12:09
  • Yes. As long as it's opaque (the client does not know or care about it). – Robert Bräutigam Jul 08 '16 at 12:25