4

I currently have a website, made of about 20 micro-services and a (still too large) main monolithic web application. The monolith and multiple micro-services each run queries to the same database, each time having to deal with login to the DB and formatting/running the queries.

I may switch our databases from SQL to NoSQL in the near future; to help this transition, as well as every future modification involving my database, I thought about creating a micro-service that will act as an access point to the database. It will handle the connection, and run the queries passed to it.

  • What would be the drawbacks of such an architecture?
  • Is passing the queries as strings a reasonable idea, or should I create a wrapper function inside the micro-service for each queries I have to run (like getThatThing() or updateThisItem())?
  • Should the micro-service be aware of the type of results for the queries, in order to return an object built with ORM?
  • hopefully, you're not sharing tables between services... /does each microservice really need its own database?; Microservices with shared database – Erik Eidt Feb 19 '18 at 14:57
  • Thanks Erik, but it's not exactly the same case. Most documentation I found talked about using the same database, and the same tables, for multiple services, whereas I was planning on using a micro-service to centralize the connection and the launch of queries to a single database, with separate tables for each services ("private-tables-per-services" in the first website). – Raphaël Feb 19 '18 at 15:05
  • You may want to look at GraphQL or similar technologies like Falcor. – Derek Elkins Feb 22 '18 at 22:15
7

What would be the drawbacks of such an architecture?

  • Single point of failureness.
  • Coupling that microservice to all others, hindering deployments and versioning.
  • That DB access service is going to be very large.

Is passing the queries as strings a reasonable idea, or should I create a wrapper function inside the micro-service for each query I have to run (like getThatThing() or updateThisItem())?

No. Passing them as strings likely means they can't be cached by the server. It also means you're leaking your query language to your consumers. If you really do want to move everything to NoSQL, are you really going to make all of your other services fix their queries? Why should they know/care?

Should the micro-service be aware of the type of results for the queries, in order to return an object built with ORM?

Maybe. I wouldn't want to make all of the consumers have to duplicate the code to turn an arbitrary table into an object. On the other hand, I'm not sure I want to couple the data access service to its consumers even harder by sharing object models.

A good compromise is maybe limiting your data so that it can fit nicely into JSON, which the consumers can then deserialize into their objects, while the data access service can just work with JSON.

But for most any scenario I can imagine, this is just a bad idea and you should avoid it.

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.