a_smooth_avocado
Hi everyone!
I’m planning to develop a microservices-oriented architecture where my Kubernetes (k8s) cluster will support different nodes: an API gateway, authentication (auth), and application (app) services. These will be integrated into a unified cluster using a DNS strategy, with the potential for one or more Elixir nodes per service. The gateway will be built as a Phoenix application featuring an Absinthe GraphQL schema. For communication between the auth and app services, I’m considering using a library like Horde to facilitate calls from the gateway. This setup aims to ensure that requests requiring immediate attention are promptly handled. Additionally, data loading between nodes would leverage similar inter-node communication techniques.
The primary goal is to create a cohesive API “front” that consolidates multiple services into a single GraphQL schema, essentially creating a unified yet flexible schema. This approach will enable advanced functionalities, such as cross-service resolvers and multi-level caching, enhancing the overall efficiency and scalability of the system.
I’m curious about the feasibility of this setup and whether I might be underestimating its complexity. I’m aware of potential challenges, like process replication, but I’m not entirely clear on how these might impact my specific architecture. I have considered doing a single monolith, however this cannot happen due to the security concerns.
Where Next?
Trending in Questions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Phoenix, LiveView, multimedia pipelines, distributed systems. 400 engineers, Elixir since 2017. Available for hire.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #blog-post
- #phoenix_html
- #iex
- #graphql
- #ai
- #genstage
- #elixirconf-us
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #security
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Practical resources that improve the lives of professional developers.
Bringing learning, work and compliance together since 1987.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
First Post!
kirega
Hi,
I dont know about the feasibility of your proposed solution. However, I would ask you to consider looking at graphql federation, it comprehensively solves the plan to have a single graphql api for a federated microservice.
Check it out here. Introduction to Apollo Federation - Apollo GraphQL Docs