Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

One of the core principles of microservices is that each service owns its own data. How is that the case if multiple services are connecting to the same database?
– Ant PJul 22 at 7:49

Well, inlux is accessed by several differents services, but I can code an API in front of it, so it is compatible with core principe you mention
– Juliatzin del ToroJul 22 at 7:55

You might just be moving the problem up by doing that. You might be better off with multiple separate data stores, for example. It's really hard to say with this broad a question.
– Ant PJul 22 at 7:57

In my case, IoT device send data to InfluxDB or Blockchain. If it sends it to blockchain, then blockchain herself will write a ReadOnly copy into Influx for faster access to data. There is several services that will read this data, but they can all be considered as clients
– Juliatzin del ToroJul 22 at 8:11

1

@JuliatzindelToro It's not just about each microservice only connecting to one database, it's about each microservice having a logically separate data model. If you have two services accessing or maintaining the same data model, you have effectively created coupling between those services. This breaks the microservices pattern, because if one service needs to change the shared data model, it will break the other service(s) that are using it. The only real solution for microservices is to have completely isolated and independent repositories. You may have to re-think your architecture.
– Aaron M. EshbachJul 23 at 14:06

I think what you're suggesting is splitting apart the data stores for the different microservices and colocating the now multiple data stores with their respective microservices. If that's the case, I agree with you, but it could be a bit more explicit. The real benefit of this is that each microservice can optimise its data store to its own ends and you don't really gain this benefit by just sticking a shared API in front of the database (in fact you probably make it worse).
– Ant PJul 23 at 13:24

If the Go application is itself a server, then I see no reason why you need to build an intermediate server to handle the DB interface. At that point you're probably over-designing things. Use the standard client libraries, that is what they are for.

If the Go application is the client (such as a command line tool) that is used 'out in the wild' on computers you don't have control over (such as end user machines), then yes, such an API would be a good idea so that you are not exposing your database to the outside world - along with all the risks associated with doing that.

Ok ! So, after reviewing all my services, I have 1 React client, so, I will need to create an API for him. All the others services are server side, so I will let them like that. The only thing I can see is that I have 2 sources of data doing the same actions, so I should probably make a shared lib with those calls, but maybe not an API
– Juliatzin del ToroJul 23 at 9:07