See Keyhole at Nebraska.Code() 2018 – Sponsoring & Speaking

Keyhole Software Articles, Community, Company News, Educational Event, GraphQL Leave a Comment

Keyhole Software is excited to once again be a Gold sponsor of the Nebraska.Code() Conference.

The 2018 conference is Wednesday through Friday, June 6th-8th with excellent technical talks on the schedule. Wednesday will consist of half and full-day workshops, while Thursday and Friday will consist of 100+ one-hour breakout sessions. This year, the conference has moved to the Mid-America Center in Council Bluffs, IA, right across the river from Omaha, NE.

Sessions To Watch
Numerous conference sessions will be led by Keyhole Software team members on a myriad of technical topics. Make sure to attend the following Keyhole sessions when setting your own personal conference calendar…

Rethinking REST Practices: An Introduction to GraphQL with AWS AppSync

Mat Warger API Development, Articles, AWS, Cloud, Development Technologies & Tools, GraphQL, JavaScript, Programming, REST 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 Articles, AWS, Cloud, Development Technologies & Tools, 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…

Service Discovery with Eureka and Zuul

Jarett Lear .NET, .NET Core, Articles, Microservices, Spring, Spring Boot 3 Comments

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…

Encouraging Good Behavior with JUnit 5 Test Interfaces

Billy Korando Articles, Development Technologies & Tools, Effective Automated Testing With Spring Series, Java, Spring, Testing 2 Comments

JUnit 5, released in September of 2017, is the first major release for the popular JUnit testing framework in a little over a decade. I recently presented on JUnit 5 at Lava One Conf in Hawaii in January. If you have heard about JUnit 5, but are not yet familiar with it, you can check out my presentation here, as well as the JUnit 5 User Guides.

While researching for my presentation, one new feature in JUnit 5 really caught my eye was the ability to declare tests on default methods in interfaces. This feature caught my eye because two issues I frequently face are encouraging developers to write automated tests and promoting consistent patterns across the enterprise. In this article we are going to look at how test interfaces can help accomplish both of these goals.