This content originally appeared on DEV Community and was authored by Chris Straw
Impetus Behind This Project
I started my formal software engineering career back in the 1990s at the search portal Excite@Home, where I was one of the primary engineers responsible for our internal server infrastructure. Over the last 20 years, I've experienced monolithic servers, the evolution of load balancer technology, the introduction of distributed applications running on cheap iron, the rise of virtual machines, and the off-loading of processing to clients via javascript and REST APIs.
For almost a decade, I've been running my own consulting shop where I've had an internal J2EE-based monolithic server performing data analytics on terabytes of complex data. My stack consisted of various J2EE EAR, WAR, and EJB components running on Wildfly mixed in with various Spring Boot modules providing REST APIs fronting a PrimeFaces-based JSF UI. The components used technologies spanning a decade of evolution and ranging from JMX to JPA to Lucene to EJB injectors and EJB Remote client calls, all built with Maven, interfacing with SonarQube, covered by unit and integration test cases, and fronting a massive Postgresql database and millions of loose files.
When COVID hit, I found myself with additional time and decided it was time for my internal project to sprout wings and fly out onto the Internet. In doing so, I discovered that my use-case would expose me to potentially tens of thousands of dollars in ongoing hosting and processing fees--clearly not something I relished taking on.
SOOO.... (and stop me if you have heard this before) in an effort to reduce costs, I decided to bite the bullet and explore the AWS/Azure/Google function-based "serverless" hosting solutions.
Reasoning Behind My Adoption of Serverless Framework and JS
Despite my dislike for what I've always viewed as unstructured "script-kiddie" solutions (e.g. Perl, Python, Javascript, etc.), the case for moving as many components as I could away from the process/memory intensive J2EE/Spring JVM solutions to a Node.js javascript architecture turned out to be overwhelming.
Likewise, despite my strong resistance to and serious reservations relating to leaving behind the structured data world of relational databases, the value premise underlying key-value pair data storage was impossible to refute. This was made doubly so by the inherently dis-coupled nature of the data in what I personally deem a properly structured REST API.
Unfortunately, I had become quite fond of Java's standardized JPA interfaces and Spring Boot's de-facto standardized Repository data access interfaces. The key-value storage solutions of DynamoDB and MongoDB lacked basic support for this functionality. Instead, one has to piece together different modules from all over the Internet, which each experiences different levels of support and continued development.
After a period of searching and evaluation, I eventually decided to move forward with a Typescript/Javascript/Node.js solution using (1) Serverless Framework for creating and tearing down the Cloud infrastructure; (2) a DynamoDB for data storage; (3) a Dynamoose interface for interacting with the database; (4) Jest as my unit testing engine; and (5) a React front-end.
This content originally appeared on DEV Community and was authored by Chris Straw
Chris Straw | Sciencx (2021-04-11T12:36:50+00:00) Background and Stack Description – Part 2 of Implementing a RESTful API on AWS. Retrieved from https://www.scien.cx/2021/04/11/background-and-stack-description-part-2-of-implementing-a-restful-api-on-aws/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.