API's Services

Our team has built numerous enterprise scale APIs capable of supporting millions of requests daily to thousands of consumers.

We utilize the latest in web API technologies, such as edge functions, serverless architectures, API gateways, etc., in your language or framework of choice to improve developer efficacy, application performance, and application stability.

REST vs GraphQL vs gRPC

All these options solve the same problem of allowing client applications and servers to communicate. When working with teams, we work to understand the use cases to create best practice solutions that will last. REST is ubiquitous and well supported but has some limitations. GraphQL and gRPC both solve some of these limitations in their own unique ways but require additional configuration and training to get started.

API Gateways

Regardless of the protocol selected or whether microservices or monolithic applications are involved, we always recommend configuring services behind an API gateway.

An API gateway validates incoming requests, handles routing them to the appropriate service, and responds to the client with response. This allows teams to utilize any infrastructure architecture to build their services while implementing a single interface for client teams looking to integrate with those services. This assists in development velocity, avoids application fragility caused by explicit resource naming, and allows for better service access security policies.

Hosted vs Serverless Solutions

Our team utilizes both hosted solutions like NestJS and distributed solutions like the Serverless Framework to create backend services. We analyze traffic, performance, technology, and budgetary constraints to help identify the ideal solution for an organization. Our goal is to help deliver best-in-class data solutions that meet product needs.

Hosted solutions are typically easier to develop and optimize for performance but come with scaling challenges in later stage organizations. Serverless solutions yield high performance and solve the scaling challenges but can be challenging to develop and fine tune due to the lack of centralized logic. Our architects will help identify the best course of action based on an organization’s long term needs and will find a balance between these options that yield the ideal result.

1. Tell us about the technology you use to build APIs supporting your front-end applications.

• We’ve built both REST and GraphQL APIs using a variety of technologies.
• Typically, we prefer NodeJS based solutions such as ExpressJS and NestJS as having a consistent language across your technology stack can help reduce the cost of developers.
• We’ve also built APIs using technologies like Ruby on Rails, Laravel, and .NET.
• We have used technologies like AWS Amplify and Hasura to help rapidly prototype and build out GraphQL schemas for front-end consumption.
• Regardless of the technology used, we usually recommend using an API gateway as the entry point for requests to allow your backend to be structured based on your needs. If there is a need for microservices, it’s easy to spin off that new service with the gateway providing a centralized means for communication.

2. What type of database do you use to normally support your applications?

• We always try to pick the best database solution for the project.
• If the data for the project will be relational, we definitely recommend traditional SQL databases like PostgresQL and MySQL.
• If data is structured into larger document systems, we might recommend NoSQL solutions such as DynamoDB or MongoDB.
• For caching, we recommend using in-memory data stores such as redis or memcache.
• There are definite trade offs with each different solution here so identifying data models and structures prior to any development is key as to choosing the best solution. It’s important to identify the appropriate solution for your needs early as replacing databases can be an extremely costly process.
• Sometimes we’ll recommend hybrid approaches depending on your data structures and needs. However, for most hybrid approaches, we’ve found PostgresQL can handle a majority of these situations.

3. Have you used an API gateway for your APIs? If yes, what purpose has the API gateway played in your application?

• We have used API gateways to help facilitate communication between our client applications and servers.
• In microservice architectures, there are many different services responsible for providing varying information. Without an API gateway, the client application would have to have knowledge of each existing service and how to authenticate against it to retrieve the appropriate information.
• API gateways allow us to create a single entry point for all requests to proxy to these various services and fetch the appropriate information in a way that does not impact the client’s bundle size.
• Using a gateway is also a great way to introduce security to your system as the services don’t have to be exposed to the public internet and can only be accessed through your single gateway allowing you to apply authorization and validators in the gateway ensuring that only valid requests are ever passed to your service resources.
• API gateways can also act as a load balancing mechanism for your application to help deal with heavy traffic to your application and only impact relevant services as requests are routed.
• We love using GraphQL as an API gateway solution as its implementation only exposes a single endpoint to all clients and requests are made through their query language that helps type your API and ensure all requests are formatted correctly.