Tldr; Checkout this: https://github.com/ConduitPlatform/Conduit
Backend development is a tricky sport, as is everything software oriented, and like all software there are things that are repeatable in its process. This is one of the first things that any software engineer learns, abstraction and reusability of code, which should be always followed to create readable, maintainable, and stable codebases. When you are a software house though, or when you have a massive API with multiple micro-services, you start having to repeat the same processes again and again. There are solutions to this matter of course, using platforms like Kong or more infrastructure-oriented ones like Istio (or any service mesh for that matter), so that you can abstract things like authentication and API management.
All possible solutions, as every solution to any known issue ever, have their drawbacks and mostly consist of lack of flexibility, high DevOps costs and, usually, getting you, at best, 70% of the way there. When I co-founded Quintessential, we started noticing a repeating pattern to our work. Our backend team always had to implement an authentication system, they had to create various CRUD routes for different database models, implement various security checks and write different APIs sometimes RESTful sometimes GraphQL. Being a digital product development company though, meant that everything we do has to make sense for our client and be in-budget. Thus, implementing each single mechanic perfectly isn’t an option a lot of the time, since the client requires an MVP, and understands features delivered and not if the API has rate-limiting or is resilient to regex DDoS attacks, or if it can easily support new changes.
This weird deadlock we found ourselves into, meant that if we want to radically increase our deliverable quality and stay in budget, we needed to create a system or a platform rather, that can take care all of the typical stuff for the backend systems, while the backend developers focused on how to implement business logic and optimize processes.
My answer to this problem is Conduit.Oh, and I almost forgot the most important part, it should be Open Source. This is a big deal for me, since Quintessential has flourished due to OSS, and the least I could do is give back to this amazing community, that helped me and my engineering team deliver cutting-edge software.
As you can see we’ve added a fair bit of functionality already, and we continue to add more while also optimizing the platform’s processes.
The core and its modules are simple grpc micro-services. They are designed to be linearly scalable and flexible so that they can change their configuration and functionality on the fly. The core contains all functionality that stores module configuration, declared routes from the modules, is responsible to enforce security and constructs 4 different routers for clients to connect to. The 2 basic ones are the REST and the GraphQL APIs, both of which have full validations and type support, so that service developers only need to specify the correct type, and the core enforces it. The other 2 routers are the admin router, which handles routes for module administration and the authorization required for conduit admins and finally the socket router, which contains all the necessary functionality to expose sockets through which modules like Chat can work.
One main differentiator of Conduit technology-wise compared to other modular/extensible platforms, is that the entirety of its overhead for configuration is handled on startup or on configuration changes. When a request comes through, each module already knows what it's supposed to do, without having to do greedy DB calls or calculations to figure it out. The result of this is nearly zero overhead on requests, which in turn means that it's behaviour is similar to what you expect for your own custom code.
Being a grpc-based platform, means that conduit has very low latency for intra-module communications. At such a point where if you were to launch the entire platform in a single machine, the latency is comparable to simple function calls (give or take few ms). Of course, we’re not even at the final optimization stage. Currently, most Conduit requests take less than 100ms to complete (authentication included), and that’s by communicating with servers that are in different countries entirely. Since we believe that conduit is currently adding a 10-15ms overhead to requests (due to JSON parsing mostly), we're already making refines to take that down to 5ms or even less.
With Conduit the question isn’t when will the API be ready, but when do you want to use it, because it’s always ready.
So, whether you’re a startup that wants to start moving quickly towards an MVP(that you won't have to rewrite once you want to scale your product), a software company that wants to decrease development costs or a just a developer wanting to play around with something, go ahead and give conduit a spin.
We’re in an early stage still, so we consider Conduit to be in Alpha stage, and we plan on rolling out a SaaS offering so that you can deploy it without having to worry about servers or updates. As with any OSS project, it would mean the world to us if you gave us a star or even better if you joined the development process to see what awesome things, we can have Conduit do!