Overview of My Submission
So basically I was exploring the concept of Microservices few days back ago to learn about how we can achieve the Microservice architecture for large scale applications and how we can reduce the dependences of multiple modules on one another and in a mean time I found out about Appwrite tool which is really helpful for backend services so I decide to explore it and found out that i can host my Microservice server to Appwrite with all features like authentication, encryption, predefine functions etc. My main concept of the submission is to divide the server in microservice module so that is any module break\no available user can still do some actions on website\app so their will be no restrictions or any performance issue.
My project is still in under development
Submission Category:
Wacky Wildcards
Link to Code
zaahmed-nisum-com
/
microservice-servers
I have create Micro Services server for chatting application using node js
microservice-servers
I have create Micro Services server for chatting application using node js
Auth server Chat server Notification server
Additional Resources / Info
Postman for API's testing
Oldest comments (2)
I've done a lot of fault tolerant stuff that scales to billions of users. A very high level way to achieve this, is something like:
The app with a default action if the API doesn't work
The end point of the app with a default action if its deeper actions don't work
Scale more servers/instances if needed, use a great reverse-proxy or API gateway scheme
It's okay to use macro services (instead of a micro server per every granularity -- an approach I call NanoServices because there's so many, you'd share a few related features together)
You don't really have to have a different database per micro service. You can use a monolithic data approach just make sure no two services acto on the same data in the same way. Were that the case, do cross service calls
It's okay to have higher level services that act as orchestrators to avoid cross-service communication
If you really need a lot of cross service communication, using a ServiceBus or Event-Driven architecture will help you.
The more microservices the more maddening it'll be maintaining them without a very good DevOps/automation strategy. Because of this we took more of a macro service architecture than a micro/nano service on. Now that we have all the automation, we're breaking each controller into a microservice as it should be. Prologinging this step has saved us a lot of pain.
Keep it as simple as possible.
For faul tolerance, that really only works if you have a failover system, a way to get to an alternate behavior, or a way to avoid a non-essential behavior. It's easier to start with a default alternate behavior (in the app, then in the service) then a scale up/failover in the DevOps side. That way you can get some reliability and time to do the hard stuff.
Thank man for deep explanation.❤️❤️❤️