Keyhole Software offers a range of services related to Microsoft Azure, helping clients leverage the capabilities of the Azure cloud platform. Services include Cloud Migration: Migrating applications and infrastructure to Microsoft Azure by assessing the existing environment, developing a migration strategy, and executing the migration process while ensuring minimal disruption to business operations. Azure App Services: Building and deploying web & mobile applications using Azure App Services, designing and implementing scalable and secure application hosting environments. Architecture & Design: Helping clients design scalable and efficient architectures on Azure, working to understand requirements and design architectures that leverage various Azure services to meet specific needs. Cost Optimization: Optimizing Azure infrastructure for cost-effectiveness by assessing resource utilization, identifying cost-saving opportunities, and providing recommendations for optimizing Azure usage and billing.
Go Forth and AppSync!
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
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…
Showcase of React + Redux Web Application Development
In the last few years, React has continuously gained popularity for the development of web applications. At Keyhole, we have several blogs talking about React and related technologies, including React, Formik, react-router, and many others.
So why would we need Redux? Quite often when we develop applications, we start with small pieces. As the business requirements change, new features/modules/components are added/removed/updated. Particularly in enterprise applications, you may end up with a deep hierarchy of parent-child relationships.
In a React application, parent component-states are passed down to its child component as property. Application states can be changed in many different places. If not managed perfectly (and, in many cases, it’s not), your system can behave differently than expected. It can become increasingly difficult for development, debugging, production support and code maintenance.
In this blog, I’ll talk about Redux and explain how it can benefit React front-end development. I’ll provide an introduction to using Redux with React and show a demonstration of reconstructing an example React application to React + Redux.
I’ll re-construct this React application into two projects. The first project will be the back-end server application which will handle all the typical business in the server end, like registration, authentication, database operation, etc. I’ll use MongoDB to persistent data and Node.js for REST API development. You can also reference RESTful API development to the Github repository open source khs-convo, released by Keyhole Software.
The second project will be pure front-end development, which will React with Redux for state management. React with Redux integration is the focus of this blog…
Service Discovery with Eureka and Zuul
One issue that we face day to day as developers is speed of development. One of the coolest things to me in the ever-changing landscape of technology is how this issue us continually being addressed in an effort to makes our lives easier.
We have gone from having to write everything needed in a verbose way to being able to configure a simple REST API in a few lines of code with Spring Boot. The most amazing part of this is not only the ability to create the web services but also the ability to allow these services to communicate in a smart way. Spring has given us many tools to allow easy configuration and putting together things that just work (mostly).
This post is not to be considered a full guide to which the extent of these technologies can be leveraged. In this post, we give examples of how Spring Boot can be used (along with Zuul and Eureka) to create a simple discovery service.
There are other components that can be added for things like a configuration server to pull all application.properties files from a common location that is updatable in real time, or circuit breakers to allow the graceful failing of different pieces of your API.
What this post will focus on is the service discovery between Spring Boot applications. We will also touch on how, using SteeltoeOSS, .NET applications can also take advantage of being a part of the service discovery and be routed through our Spring Boot-based Zuul Gateway. We will also look at how we can integrate Spring Security into our gateway to secure the entire API no matter the language…