Go Forth and AppSync!

Mat Warger Amazon Web Services, AWS, JavaScript, Technology Snapshot Leave a 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 Amazon Web Services, AWS, JavaScript, Programming, Technology Snapshot 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 Amazon Web Services, AWS, Java, Spring, Spring Boot, Technology Snapshot Leave a Comment

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…



Thoughts on Application State

Mat Warger Amazon Web Services, AWS, JavaScript, React Leave a Comment

Use Redux! Use MobX! Just use `setState`!
Redux is functional! Mobx is reactive! `setState` is built-in!
But Redux has so much boilerplate! But MobX is more difficult to debug! But `setState` doesn’t scale!
Why don’t you just use Rematch to abstract the Redux boilerplate? Do I use redux-thunk? redux-saga? redux-observable?
How about using Unstated? How about just using the Context API?

:head-explodes:

There are a lot of options for developers regarding how and when to use state management libraries (SML).

Remember those last two articles (The Joy of Forms with React and Formik & One Router to Rule Them All: React Router) about the massively underplayed game library? There was a third part to come — a follow-up meant to implement an example of state management for an application. The application was small, granted, but this somewhat contrived example would tie it all up. It’d be the cherry on top. It would complete the rule of threes. 😉

There is not going to be another tutorial about which state library we can use to better manage our game library. Rather, in this post, we’re going to look at how and why you might use a library to manage your application’s state, and why that particular application is a perfect example of when you might not need a SML at all.



OpenShift Quick Start

David Pitt Amazon Web Services, AWS, Docker, Microservices, OpenShift Leave a Comment

Our previous blog in the series introduced RedHat’s OpenShift solution that provides a way for enterprise teams to implement their own PaaS. Essentially, it sits atop the Docker-based Kubernetes platform to provide a ready-to-use DevOps platform.

This blog introduces two hands-on exercises (taken from our OpenShift Course), that work to walk you through the following tasks:

– Installing OpenShift locally
– Adding a Container with an API service to a Pod

Unfortunately, it will take more than this quick start blog to get OpenShift installed and enabled in an enterprise. That said, developers, system admins, and any party that may be working on or responsible for the platform, will benefit from understanding how to get OpenShift up and running on a local machine as shown in this blog.