Go Forth and AppSync!

Mat Warger AWS, GraphQL, JavaScript, Technology Snapshot 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, GraphQL, 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 AWS, Java, Spring, Spring Boot, Technology Snapshot 11 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…

Thoughts on Application State

Mat Warger 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.

Keyhole Sponsoring Azure Dev Days Kansas City 2018

Keyhole Software .NET, Azure, Community, Company News, Educational Event Leave a Comment

We are excited to announce Keyhole’s partnership with Microsoft to sponsor Azure Dev Days, a one-day workshop in Kansas City on Wednesday, April 25, 2018. This is a free community event to provide education on application modernization, microservices, and Microsoft Azure topics.

In addition to providing technical educators for this workshop, Keyhole Software will sponsor food and beverages. The topics Keyhole will champion include Microservices and Containers, as well as App Services.

Each technical session will be followed by a hands-on Azure lab and a whiteboard design exercise. This workshop will help attendees gain a thorough understanding of the components of Azure and how you can take advantage of them as a developer.

This is a traveling community event, with other events available to attend in St. Louis and Oklahoma City. The event will be held at the Microsoft offices in Overland Park…