Fresh, deno deploy microservices and auth
Hi,
I want to design a Fresh frontend and api working with deno microservices and auth. My proposal is on the scheme.
Is it the best way to manage auth between microservices ?
In this case, microservices can be consume directly without passing by the gateway. Is there any security problem ?
Could subhosting be an answer to isolate microservices and share a unique kv database ?
Thx for your opinions, feedback or insight
9 Replies
Hello there! 🦕
Designing a Fresh frontend with an API that works with Deno microservices and authentication is a great idea. Let's address your questions one by one:
1. Managing Auth Between Microservices:
The best way to manage authentication between microservices can vary depending on your specific requirements and architecture. However, a common approach is to use a centralized identity provider and token-based authentication (like OAuth 2.0 or JWTs). Each microservice can then validate the token independently. The documentation mentions Deno KV OAuth, which is a high-level OAuth 2.0 wrapper that can be used with Deno Deploy projects. This could simplify the implementation of authentication in your setup.
2. Security Concerns with Direct Microservice Access:
If microservices can be consumed directly without passing through an API gateway, you need to ensure that each microservice is capable of securing itself. This includes authentication, authorization, and input validation. Without a gateway to provide a security layer, the responsibility falls entirely on each microservice. It's crucial to implement proper security measures to prevent unauthorized access.
3. Using Subhosting to Isolate Microservices:
Subhosting with Deno Deploy can indeed be a solution for running untrusted code securely in isolated environments. It allows you to create deployments that are isolated from each other, which can help in isolating microservices. As for sharing a unique KV database, Deno Deploy and Deno KV can be used to provide seamless persistence for your applications. The documentation suggests that Deno KV is designed for globally distributed applications, which could be beneficial for sharing data across your microservices if they are designed to work
with Deno KV.
Remember, while subhosting can provide isolation and scalability, you'll still need to design your system's architecture to handle authentication and authorization appropriately across your microservices.
For more detailed guidance on subhosting and authentication with Fresh, you can refer to the Deno documentation on these topics:
- Subhosting: https://docs.deno.com/deploy/manual/subhosting/
- Setup Auth with Fresh: https://deno.com/blog/setup-auth-with-fresh
These resources should provide you with the necessary insights to design your system securely and efficiently. If you have any more specific questions or need further assistance, feel free to ask!
Do you need microservices? A far simpler architecture would be to have the Fresh app host the frontend and APIs, with a middleware handling the auth, and a single KV backend. All of that is a single deployable unit on Deploy.
Deploy isn't optimised for microservices in that there are limits to the number of projects you can have which means either you have a small number of microservices (each as their own Deploy project) or you group microservices together into a shared project (in which case they aren't microservices anymore).
Subhosting likely isn't a solution as it is primary use case is for running untrusted code from your users, which isn't what you are trying to achieve.
Serve API with fresh is a good idea.
I have 10 microservices in order to have a project more maintenable. In your proposal, don't i come back to a monolithic app ? what is the threshold in size of code between monolothic or microservice ?
The decision whether you go with microservices or not should never be made based on code size. A monolith is still the fastest and most efficient deployment solution to this day. The only reason to not pick a monolith is if you run into actual performances issue that cannot be solved any other way. Platforms like Deno Deploy already spin up more isolates when more traffic is coming in so that part is already taken care for you.
Breaking up a monolith can also make sense when you have multiple teams working on the same application and higher velocity can be achieved through independent deployable units. My experience is that monoliths are a great way to go for many projects, especially when they are not significantly large or involve multiple teams. The simplicity and reduced complexity of everything in one deployable unit far outweighs the gains of separating into multiple projects. Stackoverflow is a famous monolith by the way!
Same is true for Shopify. They use a monolith architecture too https://shopify.engineering/deconstructing-monolith-designing-software-maximizes-developer-productivity
Nice article 👍
Thanks for desmystify those points