# microservice-architecture Published articles for microservice-architecture. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Streamlining GraphQL Service Testing with Karate DevFeed: [Streamlining GraphQL Service Testing with Karate]() Original publisher: [Read original article]() Author: Armin Aminian SRE; Cloud Native technologies GitHub profile Linkedin profile Published: 2024-07-08T00:00:00Z Content type: article Language: en Sources: [Trivago]() Topics: [GraphQL](), [Testing](), [Microservice](), [API](), [gateway]() Tags: [api](), [architecture](), [backend](), [devops](), [gateway](), [graphql](), [integrity](), [microservice-architecture](), [quality-assurance](), [release-engineering](), [rest](), [schema](), [services](), [testing]() ### AI overview The article describes trivago's move from a GraphQL monolith to a federated microservice architecture and explains the testing challenges this creates. It covers complex nested queries, schema validation, relationships, data integrity, and GraphQL's partial-data error responses. ### Source excerpt Over the last year trivago refactored the existing GraphQL monolith and moved to a microservice architecture, in what is also known as a federated setup. Federated GraphQL, as championed by Apol... ## Micro Service Events (AWS EventBridge vs. SNS) DevFeed: [Micro Service Events (AWS EventBridge vs. SNS)]() Original publisher: [Read original article]() Author: Kristian Müller Published: 2022-09-16T12:06:51Z Content type: comparison Language: en Sources: [Homegate Engineering Blog - Medium]() Topics: [event driven](), [Messaging](), [Amazon Web Services](), [Amazon Simple Queue Service (SQS)](), [Publish-subscribe pattern](), [Architecture & Design](), [AWS Lambda](), [Amazon API Gateway](), [DynamoDB](), [Amazon S3](), [TypeScript]() Tags: [api](), [api-gateway](), [architecture](), [aws](), [aws-eventbridge](), [aws-sns](), [data](), [data-processing](), [database](), [dynamodb](), [event](), [event-driven](), [eventbridge](), [eventbus](), [events](), [gateway](), [lambda](), [messaging](), [microservice-architecture](), [s3](), [sns](), [sqs](), [typescript]() ### AI overview This article examines Homegate's event-driven microservice architecture on AWS and compares Amazon SNS with EventBridge as messaging infrastructure. It describes how services use SNS, SQS, Lambda, API Gateway, DynamoDB, and S3, and explains that EventBridge has a different focus, so replacing SNS is not necessarily the right question. ### Source excerpt During the last few years, we've been busy rebuilding the Homegate platform in an event driven, micro service architecture based on AWS. One of the most important buildings blocks, or shall we rather say the mortar that connects the building blocks, is the way our services send events to each other. While Amazon offers its notification service SNS since more than 12 years; in 2019 it started a newcomer in the messaging bus field by introducing EventBridge. This was very interesting to us as we're using SNS a lot. Bus on a Bridge (Photo by "Blue Elf" on Wikimedia Commons) As EventBridge was introduced and gained traction we asked ourselves what advantaged we would gain by switching our SNS based service glue to EventBridge. Maybe this turned out to be the wrong question for us. Let's look at our system to see why. Micro Services Connected by SNS Homegate is connecting dozens of services via SNS right now. Those services range from single purpose Lambda functions written in TypeScript to database heavy services using Aurora or DynamoDB and Step Functions sending events to other services. Some of the services are also interfacing external APIs such as Salesforce or SendGrid. Here our Lambda functions can call APIs when needed. On the other hand, we have web services to be called as APIs by other systems and end users. This is mostly achieved via API Gateway. A typical service connects to the system by subscribing to events needed to fulfill its purpose. Those inbound SNS events are then ingested via SQS allowing for orderly data processing and DLQs to handle errors. Outgoing results are pushed back to the system in form of events to a SNS topics. As Marko Savic has pointed out, we're also utilizing S3 to store and replay those events if needed. Basic AWS Lambda function connected via SNS If we would replace the SNS topic by streams on the EventBridge we would initially gain the same functionality by utilizing SQS as well. However, EventBridge has a different focus. Let ## The Evolution of GraphQL at Scale DevFeed: [The Evolution of GraphQL at Scale]() Original publisher: [Read original article]() Author: Andy Roberts Published: 2020-11-12T11:25:01Z Content type: tutorial Language: en Sources: [Apollo Blog]() Topics: [GraphQL](), [Microservice](), [Front end](), [BFF](), [API](), [Structured-data]() Tags: [api](), [architecture](), [backend](), [bff](), [development](), [frontend-development](), [graphql](), [microservice-architecture](), [schema]() ### AI overview This article explains how organizations evolve GraphQL after an initial proof of concept reaches production. It compares monolithic GraphQL APIs, backend-for-frontend implementations, and Federation, while discussing the organizational and architectural trade-offs involved. ### Source excerpt Most organizations' adventures with GraphQL start with one team looking for a way to solve one of the most significant frontend development problems in a microservice architecture: how to get all the data your app needs without making a million and one service calls. For a frontend engineer, that promise of getting all the data they need, in the exact shape they envision using it (and with only a single request) is often too hard to resist. It's here where a proof of concept comes to fruition. ## Apollo Federation DevFeed: [Apollo Federation]() Original publisher: [Read original article]() Author: James Baxley III Published: 2019-05-01T22:00:00Z Content type: release Language: en Sources: [Apollo Blog]() Topics: [GraphQL](), [Microservice](), [Open Source](), [data]() Tags: [announcement](), [apollo](), [apollo-federation](), [architecture](), [declarative](), [distributed](), [graphql](), [launch](), [microservice-architecture](), [monolithic-architecture](), [open-source](), [product](), [schema](), [services]() ### AI overview Apollo introduces Apollo Federation, an open-source architecture for building a distributed GraphQL graph across microservices. It aims to replace schema stitching by letting teams declaratively compose a unified graph while owning separate portions of the schema. ### Source excerpt What if you could access all of your organization's data by typing a single GraphQL query, even if that data lived in separate places? Up until now, this goal has been difficult to achieve without committing to a monolithic architecture or writing fragile schema stitching code. Ideally, we want to expose one graph for all of our organization's data without experiencing the pitfalls of a monolith. ## Monolith to Microservice: Architecture Behind V2 Webhooks DevFeed: [Monolith to Microservice: Architecture Behind V2 Webhooks]() Original publisher: [Read original article]() Author: Paulius Jakimavičius Published: 2017-09-11T15:09:33Z Content type: article Language: en Sources: [Teamwork]() Topics: [Microservice](), [Architecture & Design](), [Go Language](), [HTTP](), [JSON](), [XML](), [JavaScript](), [callback]() Tags: [api](), [architecture](), [go](), [http](), [javascript](), [json](), [microservice-architecture](), [sha256](), [teamwork](), [teamwork-project](), [webhooks](), [xml]() ### AI overview This article explains the redesign of Teamwork Projects webhooks from a monolithic implementation to a Go microservice. The update supports multiple webhooks per event, sends complete datasets in JSON, XML, or form format, adds SHA-256 checksums, and uses more frequent retry intervals. ### Source excerpt We've recently released an update to the Teamwork Projects webhooks feature and I was asked to do a tech talk on the topic, a recording of which can be found below. This article is a rough summary of the talk with further elaboration of the thought process behind some of our decisions, but in summary: We have a microservice written in Go. We now support multiple webhooks per-event We send full datasets in chosen format (JSON, XML or Form) We offer better security and integrity with sha256 checksums We have more frequent retry intervals. https://medium.com/media/1208334bf98663ab7d55e4d2eaad4c95/hrefWhat are Webhooks? The basic idea of webhooks is simple -- it's a HTTP POST call triggered when some event occurs. You can think of it like a JavaScript callback, except it's a HTTP POST that can be sent anywhere, to anyone -- not limited to a single codebase or domain. In the case of Teamwork Projects, we have a set list of possible events you can subscribe to, denoted in OBJECT.ACTION style, so for example TASK.CREATED or MESSAGE.DELETED. Previous Approach (v1) Our original approach was no more complicated than the concept of webhooks itself -- when any of the supported actions are taken in Projects, a "fireWebhook" function is called, which checks if they're enabled and if there is a webhook set up for that event. If all is good -- we make a cfhttp call to the relevant URL with the item ID, item type and the action taken, all encoded as form data. Now there are a few limitations with this approach which showed up as the number of webhook users increased over time: Only one webhook per event -- although it made sense as a sort of anti-spam measure initially, this resulted in a few inconveniences for our customers. For example, a user sets up a TASK.CREATED webhook that notifies a custom service which adds the task ID to their internal database. This would make it impossible for them to later set up, say a Zapier zap using TASK.CREATED event as it is already "in use". Limited ## Faster App Recovery With Bounded Queues DevFeed: [Faster App Recovery With Bounded Queues]() Original publisher: [Read original article]() Author: Zachary Anker Published: 2017-06-21T18:08:07Z Content type: tutorial Language: en Sources: [Square Corner Blog RSS Feed]() Topics: [Ruby](), [nginx](), [Benchmark](), [Testing](), [Microservice]() Tags: [app](), [architecture](), [automated](), [benchmark](), [code](), [engineering](), [http](), [microservice-architecture](), [nginx](), [outage](), [queue](), [request](), [responses](), [ruby](), [server](), [test](), [timeout]() ### AI overview This tutorial explains how bounded request queues can help Ruby applications recover after downstream failures. Using NGINX, Puma, client retries, and benchmark tests, it shows how unbounded queues and repeated timeouts can create backlogs and cascading failures, and why rejecting requests when overloaded can reduce the need for restarts. ### Source excerpt Get your app back up more rapidly using bounded queues ## Upgrading a Reverse Proxy from Netty 3 to 4 DevFeed: [Upgrading a Reverse Proxy from Netty 3 to 4]() Original publisher: [Read original article]() Author: Square Engineering Published: 2016-08-09T16:12:00Z Content type: article Language: en Sources: [Square Corner Blog RSS Feed]() Topics: [Netty](), [HTTP](), [Microservice](), [Java](), [Remote Procedure Call (RPC)](), [gRPC](), [Mobile]() Tags: [engineering](), [http](), [infrastructure](), [java](), [memory](), [microservice-architecture](), [migration](), [performance](), [proxy](), [rpc](), [threading](), [upgrade]() ### AI overview Square describes upgrading Tracon, its reverse HTTP proxy powered by Netty, from Netty 3 to Netty 4. The article explains the motivation for the migration, including Netty 3 reaching end of life and the need to proxy HTTP/2 for mobile clients and gRPC infrastructure, and discusses issues encountered during the completed upgrade. ### Source excerpt Tracon is our reverse HTTP proxy powered by Netty. We recently completed an upgrade to Netty 4 and wanted to share our experience. ## Protecting infrastructure secrets with Keywhiz DevFeed: [Protecting infrastructure secrets with Keywhiz]() Original publisher: [Read original article]() Author: Square Engineering Published: 2015-04-14T16:08:00Z Content type: article Language: en Sources: [Square Corner Blog RSS Feed]() Topics: [Security](), [Microservice](), [Architecture & Design]() Tags: [certificates](), [distribution](), [engineering](), [infrastructure](), [microservice-architecture](), [secrets](), [security](), [ssh](), [tls]() ### AI overview Square describes Keywhiz, an open-source service for centrally managing and distributing infrastructure secrets such as TLS certificates, keys, database credentials, API tokens, and SSH keys. The article explains the security and operational requirements that shaped the system. ### Source excerpt Our newly open-sourced secret management and distribution service ## gRPC -- cross-platform open source RPC over HTTP/2 DevFeed: [gRPC -- cross-platform open source RPC over HTTP/2]() Original publisher: [Read original article]() Author: Square Engineering Published: 2015-02-26T17:08:00Z Content type: article Language: en Sources: [Square Corner Blog RSS Feed]() Topics: [gRPC](), [Remote Procedure Call (RPC)](), [cross-platform](), [Open Source](), [HTTP](), [Google](), [Microservice]() Tags: [architecture](), [c-plus-plus](), [c-sharp](), [cross-platform](), [engineering](), [github](), [go](), [google](), [http](), [java](), [library](), [microservice-architecture](), [node](), [objective-c](), [open-source](), [php](), [pull-requests](), [python](), [rpc](), [ruby](), [streaming]() ### AI overview Square describes collaborating with Google to open source gRPC, a BSD-licensed, cross-platform library for remote procedure calls over HTTP/2. The article explains its use in client-server and server-server communication, along with claimed benefits including binary-protocol efficiency, type safety, smaller memory footprint, bidirectional streaming, multiplexing, flow control, and header compression. ### Source excerpt Collaborating with Google on open sourcing gRPC