Below you'll find a list of all posts that have been categorized as “Cloud”
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!
Earlier this month my friend Ryan introduced us to Getting Started with Xamarin Forms and Prism. In that post, Ryan started a mobile application to display blog posts which he called SimpleBlog.
In this article, I would like to continue that demonstration by adding a back-end server to persist and share these blogs. This will be accomplished using Azure’s Mobile App Service which falls within its free tier services.
Yes, you did read that right: you can spin up an Azure account and have access to try out many of Azure’s features. For instance, the example I am going to walk you through today can be hosted indefinitely without costing you anything, and to that, you could add nine more web, mobile, or API services. See https://azure.microsoft.com/en-us/free/ for more information.
There is no way I am going to be able to cover all the possibilities available in an Azure Mobile App service, much less what Azure has to offer. My intent in this post is to help “whet your appetite” on the possibilities by giving a quick overview of just two great frameworks that play great together: the Microsoft.Azure.Mobile.Client mobile framework tied to an Azure Mobile Apps Service….
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….
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…
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…
