I am working with a team to expose a database as an API. With projects like this, there can be a lot of anxiety in exposing a database directly as an API. Security is the first one, but in my experience, most of the time security is just cover for anxiety about a messy backend. The group I’m working with has been managing the same database for over a decade, adding on clients, and making the magic happen via a whole bunch of databases and table kung fu. Keeping this monster up and running has been priority number one, and evolving, decentralizing, or decoupling has never quite been a priority.
The database team has learned the hard way, and they have the resources to keep things up and running but never seem to have them when it comes to refactoring it and thinking differently — let alone tackling the delivery of a web API on top of things. There will need to be a significant amount of education and training around REST and around doing APIs properly before we can move forward — something there really isn’t a lot of time or interest in doing. To help bridge the gap, I am suggesting that we do an entirely new API with its own database and that we focus on database-to-database communication since that is what the team knows. We can launch an Amazon RDS instance with an EC2 instance running the API and the database team can work directly with RDS (MySQL), which they are already familiar with.
No comments:
Post a Comment