Using Amazon ElastiCache for Redis To Optimize Your Spring Boot Application

Brandon Klimek AWS, Development Technologies, Java, Spring, Spring Boot 13 Comments

Has your project gotten to the point when big data sets and/or time-consuming calculations have begun to affect performance? Or are you struggling to optimize your queries and need to cache some information to avoid continually hitting your database? Then caching could be your solution.

For this article, I will demonstrate how to utilize Amazon ElastiCache for Redis to speed up areas of your application. The example application we will build uses Spring Boot 2.x and is available on Github.

AWS AppSync with Lambda Data Sources

Mat Warger AWS, Development Technologies, GraphQL, JavaScript, Tutorial Leave a Comment

The power of GraphQL lies in its flexibility. That is especially the case regarding resolvers, where any local or remote data can be used to fulfill a GraphQL query or mutation.

In this post, I’m going to demo a quick example of what this looks like, and a couple gotchas that were apparent in working with Lambdas as a data source for AppSync. Let’s gooooo!

Go Forth and AppSync!

Mat Warger AWS, Development Technologies, GraphQL, JavaScript 1 Comment

In a previous post, we discussed the basics of GraphQL and how it can be a great REST API alternative. In this one, we’ll see how AppSync can be more than just a great API alternative — it gives you a soft landing into the world of GraphQL.

Recall our Game API example? Let’s start with the basic type of a game. Follow along and we can implement a simple schema in AppSync together….

Rethinking REST Practices: An Introduction to GraphQL with AWS AppSync

Mat Warger AWS, Development Technologies, GraphQL, JavaScript, Programming Leave a Comment

The basic premise of data transfer and involves requesting and receiving lists. This is simplistic, but it gets to the root of why we’ve developed the technologies and best practices to pass data using web services. RESTful APIs have grown to serve the needs of numerous individuals, startups, and enterprise companies across the world. They are useful, productive, and the concepts surrounding them are relatively standardized. If you don’t know how to create one, you can quickly find information building a great API that can grow to fit your needs. That’s when things get complicated…

If you start digging into REST, you’ll realize there’s quite a bit more to throwing lists. There are common threads that many people encounter when developing an API, and you begin to encounter many of the same questions so many others have before, such as: How strictly should you adhere to the principles of REST? How should you handle versioning? Should you bother? How do you want to structure your objects? Are users able to easily figure out what API endpoints are available and how they should be used?

There are many ways approach these. It boils down to communicating the structures that a given endpoint will return or accept. The cascade of questions that results from the choices made here will ripple through from the back-end to the client. The secondary issue is that these questions and choices are not at all uncommon. There are answers to these that follow Best Practices. But there is still plenty of ambiguity involved when attempting to build a flexible API that works well. These are the Commonly Tolerated Situations.

If you hadn’t already guessed, there is a solution that frees us from the dogma of REST and allows us to solve all these issues in a declarative, powerful, and fun way. That solution is GraphQL. In this blog, I’ll provide an introduction to the GraphQL specification with code examples…

AWS Lambda with Spring Boot

Greg Emerick AWS, Development Technologies, Java, Spring, Spring Boot 12 Comments

The typical deployment scenario for a Spring Boot application in AWS involves running the Java application on an EC2 instance 24 hours a day. Of course, the application could be deployed in AWS ECS as a Docker container, but it still runs continuously on an EC2 instance. In each case, the EC2 instances need to be monitored and you pay for compute capacity used by that EC2 instance.

AWS Lambda provides low cost compute with zero maintenance. Lambda runs your code on demand, without provisioned and managed servers. Lambda automatically runs and scales your code. You are charged for every 100ms your code executes and the number of times your code is triggered. If the code isn’t running, you pay nothing.

Lambda has clear cost and maintenance benefits. But what does it take to run the standard Spring Boot application as a Lambda? How does it work? What are the drawbacks? These are the questions that will be answered in this blog through a tangible example…