Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reducing complexity by integrating through the database

fauna.com

Post reply on HN
Print view View original

41–45 of 45 posts

Re: Reducing complexity by integrating through the database

#41

Post by dennisy »

joshuanapoli wrote: post #39
dennisy wrote: post #35

Earlier quoted context omitted.

I agree, but would you mind providing a concrete example of: > No matter how you integrate different applications, be it via APIs, messaging, or a database, it's vital to separate your application's internal data model from models which it exposes. Especially in respect to this product.

Over time, the internal data model might need to change to more accurately model the world. For consistency and efficiency, we usually do not want to maintain the combination of the original low-fidelity model and new high-fidelity model within the internal database. The internal data model might need to be reorganized to improve the efficiency of part of the internal application. A client might not need a higher fid…

Great thanks.

So we have a DB and a service in front of it. The DB gets a new schema, but the service maps to the previous representation in such a way that clients do not need to know about the new schema. Is that the gist?

Then when it comes to using Fauna, what is it that does not allow such a data flow?

Re: Reducing complexity by integrating through the database

#42

Post by dennisy »

dennisy wrote: post #35
gunnarmorling wrote: post #33

No matter how you integrate different applications, be it via APIs, messaging, or a database, it's vital to separate your application's internal data model from models which it exposes. If you don't do that, you're in for a never-ending story of upstream services unknowingly breaking downstream services, or upstream services not being able to evolve in any meaningful way. So if they mean directly exposing a service's…

I agree, but would you mind providing a concrete example of: > No matter how you integrate different applications, be it via APIs, messaging, or a database, it's vital to separate your application's internal data model from models which it exposes. Especially in respect to this product.

Interesting read, but seems like a tangential topic?

Re: Reducing complexity by integrating through the database

#44

Post by newaccount74 »

gunnarmorling wrote: post #33

No matter how you integrate different applications, be it via APIs, messaging, or a database, it's vital to separate your application's internal data model from models which it exposes. If you don't do that, you're in for a never-ending story of upstream services unknowingly breaking downstream services, or upstream services not being able to evolve in any meaningful way. So if they mean directly exposing a service's…

> it's vital to separate your application's internal data model from models which it exposes

It really depends.

If you have many different client services that need to access the database in a similar way, then you are right, it makes sense to add some type of abstraction. Then you can change the underlying model and only need to update the common logic once.

Example: if two services both need to create user accounts, it makes sense to encapsulate the logic for creating user accounts somewhere. (A common practice is to use stored procedures inside the database for that)

But if the services access the database in very different ways, then your abstraction may end up just making things more complicated. You'll have just as much work to update as if you updated all the services individually.

Example: An internal dashboard may need to access the data in unique ways. If you route the dashboard service through some middle layer, then that middle layer would have lots of APIs that are used only by the dashboard. So you gain nothing from the abstraction. Any change to the dashboard requires updating the middle layer, any change to the database also requires updating the middle layer. It's just as much effort to make changes as if there was no middle layer, you've just split the dashboard logic in two parts and made it harder to understand.

Re: Reducing complexity by integrating through the database

#45

Post by newaccount74 »

snicker7 wrote: post #43

Putting more of your application logic in your database is great for DB vendors. Its pretty much impossible to migrate to a competitor.

Putting more of your application logic in the middleware is great for middleware vendors. It's pretty much impossible to migrate to a competitor.
Post reply on HN