Keyhole Software specializes in high-quality React development and consulting. Build scalable, high-performance React applications with our vetted U.S.-based experts.
A Reactrospective: A React Retrospective
Most, if not all, of my experience has been with .NET and .NET Core. I’ve also worked with most of the front-ends throughout history including Classic ASP, Code Behind, Model View Presenter, MVC, Backbone, and, over the last few years, Angular 1… Angular 6… not Angular 2…AngularJS. To me, AngularJS is that old t-shirt that you put on to sleep in; comfortable.
At first, most of us on the team were a bit apprehensive about moving to React. AngularJS was very familiar and Angular 2 seemed like the natural next step. I could learn TypeScript, and as primarily C#-based developer, I really liked the idea of a little typing. I like shiny new things, and I’m always game to learn, so challenge accepted. Since then I’ve had a hand in writing three applications in React and have learned more than a few lessons. These are their stories… dun dun.
React vs. Angular: A Comparison Between Two Great Options
Both React and Angular are very popular front end development frameworks. In this post, I will discuss the similarities and differences between the two, and consider when one should be used instead of the other.
React is an open-source JavaScript library introduced by Facebook to build dynamic user interfaces. It is based on JavaScript and JSX (a PHP extension) and is considered widely for developing reusable HTML elements for front-end development.
Angular is an open-source front-end development framework powered by Google. It is a part of the MEAN stack and is compatible with a large number of code editors and is considered for creating dynamic websites and web apps.
In this post, we will begin by going over the benefits of React and Angular, then break down the differences between the two frameworks using thirteen attributes. By comparing each framework side by side, it can help decide which is the best framework for your specific app project.
Building a Spring Cloud Native Microservice Application on Azure, Part 1
The big three cloud providers (AWS, Azure, and Google Cloud, in that order) have their various strengths and areas of expertise. Most large organizations though typically pick one cloud provider for their cloud computing needs. This works well if you’re a Java shop that’s on AWS, or a Microsoft shop on Azure. But what if you’re on a large Java project in an organization that wants to use Azure? You’re in luck.
Microsoft Azure has come a long way, and is very supportive of non-Microsoft technologies. The proof though is in the pudding. Which is where this blog post comes in. I take Josh Long’s Bootiful Microservice Services, a great starting point to get a cloud native Spring microservice application up and running, and show how it can be run on Azure.
This first blog post will be all about setting up our basic microservices by walking through the various parts of Josh’s example application, with some best practices and patterns that I’ve found to be effective. Rather than a simplistic ToDo application, we’ll be basing our application off of my favorite bagel shop in New York, Original Bagel Boss in Hicksville, to manage its orders, inventory, etc. If we can run a bagel shop on a Spring application running on Azure, and keep customers happy and full of carbohydrates, then it proves out for applications of a similar size and complexity.
We’ll be staying mostly inside the familiar Java confines, then slowly start working our way out to getting our application deployed to Azure. Then we’ll start introducing additional complexity like Spring Batch jobs, a React front end, etc. A setup this complex will show that Azure is ready for prime time when it comes to running applications in production, even if they are built on non-Microsoft technologies…
Generate Strongly Typed React Components with GraphQL
When developing in React, using a type system (like Typescript or Flow) can be a great help. You can be sure that your props and state are what you expect, at build-time, and code your components to match.
But what happens when you’re calling to an API to fetch some data, and the shape of that data is what really matters? Maybe the data get passed as props to a child component? You can create types for this, sure, but are they correct? Probably not! Or at least, probably not for long! Things change. Wouldn’t it be great if your types changed too?
In this post, we’re going to take a simple component from zero type awareness to fully typed, with local variables and GraphQL queries included, with a simple workflow. Grab a cup of coffee and a snack, and let’s see how this we can use GraphQL to generate type-safe components in React.