Skip to main content
Question Protected by gnat
Became Hot Network Question
edited title
Link
user469823
user469823

Is the separation of a databsedatabase process from the main backend process really "good practice"?

added 3 characters in body
Source Link
user469823
user469823

In our current architecture, we have a React frontend communicating with a Rust backend via REST calls. We are considering introducing a PostgreSQL database, and my colleague suggests that we should separate the database access into a distinct Java/JPA API, resulting in the following architecture:

React frontend --> REST calls --> Rust Backend --> REST call --> Java/JPA API --> PostgreSQL

I believe that we could simplify our architecture by allowing the Rust backend to access PostgreSQL directly using a library like Dieseldiesel.rs, thus avoiding the overhead of an additional microservice.

What are the potential advantages and disadvantages of outsourcing database access to a separate Java/JPA API, as my colleague suggests? Is this really "good practice", or something he just thinks he is.

Context: He is a university-trained programmer and used to lead teams, I am just a junior programmer trying to understand this. Our service is a small service used internally.

In our current architecture, we have a React frontend communicating with a Rust backend via REST calls. We are considering introducing a PostgreSQL database, and my colleague suggests that we should separate the database access into a distinct Java/JPA API, resulting in the following architecture:

React frontend --> REST calls --> Rust Backend --> REST call --> Java/JPA API --> PostgreSQL

I believe that we could simplify our architecture by allowing the Rust backend to access PostgreSQL directly using a library like Diesel, thus avoiding the overhead of an additional microservice.

What are the potential advantages and disadvantages of outsourcing database access to a separate Java/JPA API, as my colleague suggests? Is this really "good practice", or something he just thinks he is.

Context: He is a university-trained programmer and used to lead teams, I am just a junior programmer trying to understand this. Our service is a small service used internally.

In our current architecture, we have a React frontend communicating with a Rust backend via REST calls. We are considering introducing a PostgreSQL database, and my colleague suggests that we should separate the database access into a distinct Java/JPA API, resulting in the following architecture:

React frontend --> REST calls --> Rust Backend --> REST call --> Java/JPA API --> PostgreSQL

I believe that we could simplify our architecture by allowing the Rust backend to access PostgreSQL directly using a library like diesel.rs, thus avoiding the overhead of an additional microservice.

What are the potential advantages and disadvantages of outsourcing database access to a separate Java/JPA API, as my colleague suggests? Is this really "good practice", or something he just thinks he is.

Context: He is a university-trained programmer and used to lead teams, I am just a junior programmer trying to understand this. Our service is a small service used internally.

Source Link
user469823
user469823

Is the separation of a databse process from the main process really "good practice"?

In our current architecture, we have a React frontend communicating with a Rust backend via REST calls. We are considering introducing a PostgreSQL database, and my colleague suggests that we should separate the database access into a distinct Java/JPA API, resulting in the following architecture:

React frontend --> REST calls --> Rust Backend --> REST call --> Java/JPA API --> PostgreSQL

I believe that we could simplify our architecture by allowing the Rust backend to access PostgreSQL directly using a library like Diesel, thus avoiding the overhead of an additional microservice.

What are the potential advantages and disadvantages of outsourcing database access to a separate Java/JPA API, as my colleague suggests? Is this really "good practice", or something he just thinks he is.

Context: He is a university-trained programmer and used to lead teams, I am just a junior programmer trying to understand this. Our service is a small service used internally.