This particular demo addresses farm animals, so assume that I pulled data (pictures, record details) into one HTML file for each animal. In this case, imagine combining data from multiple database tables into a single HTML representation. That source – whether a (relational) database or line of business system – may have data organized in a different way that what’s needed by the consumer. This pattern relies on a process that takes data from a source, and converts it into ready to consume HTML. In this blog post, I’m going to show you how I created a flat file database in S3 and pulled the data into a Node.js application. You can also read a great Hacker News thread on this “flat file database” pattern as well. In this way, the source system (IMDB) could make scheduled or real-time updates to their HTML snippet library, and (and others) could pummel S3 as much as they wanted without impacting IMDB. What was that database? It was HTML snippets produced by IMDB and stored in the hyper-scalable Amazon S3 object storage. Their solution was to decouple and IMDB by injecting a a shared database between them. pulls data from IMDB to supplement various pages, but they saw that they were forcing IMDB to scale whenever had a burst. Vogels talked about the tight coupling that initially existed between and IMDB (the Internet Movie Database). One of my solutions was inspired by Amazon CTO Werner Vogels who briefly discussed this scenario during his keynote at last Fall’s AWS re:Invent conference. In the “shared database” module of the course, I discussed integration options where parties relied on a common (cloud) data repository. In my latest Pluralsight video training course – Patterns of Cloud Integration – I addressed application and data integration scenarios that involve cloud endpoints.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |