conduitplatform / conduit Goto Github PK

Describe the bug
REST router currently refreshes excessively due to refreshRouter() directly refreshing the Express router instead of scheduling a refresh based on a timeout, much like registerRoute() and registerConduitRoute() already do.

To Reproduce

1. Set a breakpoint in REST controller's refreshRouter()
2. Debug Core by itself
3. Notice excessive refreshes

N of refresh calls would differ based on previously registered routes, but on a fresh Redis state it should be 1.

Expected behavior
refreshRouter() should schedule a router refresh instead of directly refreshing Express.

Describe the bug
Admin routes no longer go through AdminMiddleware (masterkey header).
Admin's AuthMiddleware (adminToken Authentication header) is unaffected.

To Reproduce
Steps to reproduce the behavior:

1. Send any admin request without passing in the masterkey header.
2. Make sure you're still passing in an Authentication header (JWT admin-token).
3. Notice how the request succeeds.

Expected behavior
Request should respond with a 401 - Unauthorized.

Describe the bug

Email publishes an activation event (email:status:activated) during its onConfig lifecycle.
This event is subscribed upon by Authentication and Forms.

There is a couple of things to be fixed here:

1. Email's event always publishes an empty string as its message, while both Authentication and Forms act on a value of enabled.
2. Forms actually subscribes to email-provider:status:activated instead.

Working on a fix.
I'll backport any necessary fixes.

Describe the bug
SwaggerGenerator currently hardcodes the following non-admin headers as its header security scheme:

• security client id
• security client secret
• Bearer user token

Admin routes require masterkey and a JWT prefixed admin token instead.

To Reproduce
Steps to reproduce the behavior:

1. Go to /admin/swagger
2. Click on 'Authorize'
3. Notice the incorrect headers

Expected behavior
Each Swagger instance should expose the appropriate headers.
Pass a securityScheme object to SwaggerGenerator through RestController.

Checklist

• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the Issue Tracker for a bug that matches the one I want to file, without success.
• This issue is not related to Conduit Admin Panel.
• This issue is not related to Conduit CLI.

Conduit version

0.15.15

Describe the Bug

Hi conduit team.

I found a little bug in your url for OAuth providers. If you start the auth flow with http://localhost:3000/authentication/init/github for example, you construct a login url to github, which looks like this https://github.com/login/oauth/authorize??client_id=4a66c55... (2 question marks).
Could you please correct this and remove the excess question mark?

Expected Behavior

The login url should only contain 1 question mark
https://github.com/login/oauth/authorize?client_id=4a66c55...

How to Reproduce

Just spin up your Conduit App and goto http://localhost:3000/swagger/#/authentication/get_authentication_init_github and start the auth flow. You will see in the response the wrong url.

Additional Information

No response

Environment

No response

Is your feature request related to a problem? Please describe.
Currently health checking is being done by this simple process:

It works well enough, but it's not common practice and it simply checks if the grpc server is online. We're getting no proper health statuses and we're using an http client to check a grpc server which isn't really that great.

Describe the solution you'd like
The modules should implement (through the grpc-sdk) the Health Checking protocol of grpc as defined here:
https://github.com/grpc/grpc/blob/master/doc/health-checking.md

The config module should then be able to use the Watch rpc stream to get health status updates or at the very list make individual requests (as it's happening now but through grpc) to get better sense of the actual service status.

It'll also be more in line with common practices around grpc

Checklist

• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the Issue Tracker for a bug that matches the one I want to file, without success.
• This issue is not related to the Conduit Admin Panel user interface.

Conduit version

0.15.3

Describe the Bug

in Swagger (JSON and UI) are schemas that are deleted or CRUD was changed and not all CRUD operations are available

• [ ]

Expected Behavior

Remove not available APIs when CRUD changed or schema is deleted

How to Reproduce

1. deploy setup
2. create schema
3. set any CRUD to enable
4. check if Swagger added API
5. delete schema or disable any CRUD
6. Swagger has API entries that don't exist

Additional Information

No response

Environment

Endevuor OS (Arch Linux)

Is your feature request related to a problem? Please describe.

Bus events are currently broadcasted explicitly.
While we obviously can't always avoid this, we should make sure that certain key event types are always emitted in a predetermined and consistent way.

That should not only help us avoid bugs due to unmaintained module-specific code, but also create a solid foundation for third party modules being capable of assuming a specific event is going to be available for them to subscribe to.

Describe the solution you'd like

For instance, we could be emitting a namespaced event during each (or some) module lifecycle step.
That way we can not only safely assume that events are actually emitted for (almost) every single module, but also that the event name itself is also properly formatted (eg using the target "step" name as well as the module name).

The problem with relying on lifecycle hooks for this is that any third party modules making direct use of ConduitServiceModule (instead of ManagedModule and ModuleManager) are not going to take advantage of this.

Which isn't really a big deal as long as our own official modules either make use of ManagedModule or explicitly emit these events too.
This last bit is required in order for third party modules safely assuming that the events are consistently there across official modules.

Describe alternatives you've considered

We could alternatively publish configuration related events through Config.
That should also cover direct inheritors of ConduitServiceModule at the expense of being extremely limited in the amount of event types we can automate.

Is your feature request related to a problem? Please describe.
Currently if a user wants to connect Conduit into an existing database, they will have to import all existing schemas one by one. A process which will be tedious and error-prone, with possible destructive consequences on SQL DBs

Describe the solution you'd like
We need to add a feature, that will also require new UI in the admin panel, which once connected to a database Conduit will provide the user with the option to introspect the DB. For SQL dbs this is fairly straightforward since the schema is pretty-much already there, but for MongoDB we'll need to do document scans to understand the schema of each collection.

Additional context
Some things to consider:

• This process absolutely needs the admin UI, so that the user can confirm what Conduit detected and wants to import so that no migrations get fired incorrectly.
• For MongoDB we may even need to support multiple schemas that target the same collection. Code-wise this is already supported, but on the admin UI it is assumed that a schema and a collection have 1-1 relations
• Indexes are not properly supported but will be required for introspection since SQL uses them for foreign_keys (I think).
• Foreign key support is kinda sketchy as far as I can remember so we definitely need to look into that
• The database module will probably need some sort of change, because once online it will try to register clientid/secret schemas, the declaredSchema etc. We have virtually 2 options. 1 make sure that our schema naming is super unique, 2 check for schema existence before trying to register. And if the schema exists in the actual database but not in our declared schemas, we should print an error that an introspection needs to be made first. This still leaves us with the issue of ex. AccessToken schema from Authentication were if it already exists we cannot use it and the modules should't handle fallback scenarios. So probably the database will either need to make the schema collection name unique, or some other approach that I can't think of.

Is your feature request related to a problem? Please describe.
As another filtering option on the Custom Endpoints tab, we would like to show endpoints related to certain Schemas in order to present them as a drop-down menu.

Describe the solution you'd like
A new endpoint filtering the endpoints that have Custom Endpoints.

Describe alternatives you've considered
This could be achieved on the front-end side but would not be as clear and concise.

Additional context
Add any other context or screenshots about the feature request here.

Describe the bug
When uploading an image to file storage of conduit, for images > ~3mb then the api returns status code 413

To Reproduce
Steps to reproduce the behavior:

1. Try to upload a new image to conduit file storage
2. For images > 3mb of size
3. The api call returns status code 413 request entity too large

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context

• Conduit version: 0.10.6

Describe the bug

The Config module currently expects any configurable modules being brought up, or at the very least attempt communication, after Database so that the Config schema can be registered and the module service becoming functional before any incoming requests make their way through gRPC.

This is especially a problem for modules expecting to migrate their configuration early in their initialization.

To Reproduce
Steps to reproduce the behavior:

1. Bring up Core
2. Start Authentication
3. Start Database
4. Notice errors (eg No database instance provided! as a result of uninitialized Config model singleton)

Expected behavior
Config should probably be caching early configuration requests and performing them once ready(?)
Otherwise, Conduit's initialization will have to be reworked so that Config is becomes serviceable before modules get a chance to communicate with it.

CodeFactor found multiple issues:

yarn cache clean missing after yarn install was run.

• modules\authentication\Dockerfile:11
• packages\Dockerfile:7
• modules\storage\Dockerfile:7
• modules\sms\Dockerfile:7
• modules\push-notifications\Dockerfile:7
• modules\forms\Dockerfile:7
• modules\email\Dockerfile:7
• modules\database\Dockerfile:7
• modules\chat\Dockerfile:7

Checklist

• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the Issue Tracker for a feature request that matches the one I want to file, without success.

Suggestion

When creating a new issue there is an option to join Discord server. When I open the link, it says that invitation link is invalid.

Is your feature request related to a problem?

There is no way to manage scopes when authenticating with third party providers.
Conduit supports only scopes that are related with the profile details of each provider.

Describe the solution you'd like
Maybe it will be good to "map" the scopes with the details that this scope provide.
For example:
When authenticating with facebook the public_profile scope should be mapped with the facebook profile details.

Checklist

• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the Issue Tracker for a bug that matches the one I want to file, without success.
• This issue is not related to the Conduit Admin Panel user interface.

Conduit version

0.12.6

Describe the Bug

GET admin/router/middlewares does not work properly.

Expected Behavior

Response should be an array of strings which include the names of registerMiddlewares.

How to Reproduce

To reproduce this bug just hit this curl.

curl --location --request GET '**CONDUIT_URL**/admin/router/middlewares' \
--header 'Authorization: Bearer "adminToken" \
--header 'masterkey: "yourmasterkey"

Additional Information

No response

Environment

macOS Monterey 12.3.1

Checklist

• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the Issue Tracker for a feature request that matches the one I want to file, without success.

Suggestion

There are a lot of storage providers that are S3 compatible along with Amazon AWS (i.e Backblaze, Wasabi, etc...). The bulk of the groundwork has been done by implementing it as AWS S3, so I think it'll be pretty easy to make the S3 implementation generic rather than specific to AWS only. I was able to create a bucket and upload to Backblaze by simply specifying the Backblaze endpoint as part of the S3ClientConfig object.

  constructor(options: StorageConfig) {
    const config = {
      region: options.aws.region,
      credentials: {
        accessKeyId: options.aws.accessKeyId,
        secretAccessKey: options.aws.secretAccessKey,
      },
      endpoint: 'https://s3.us-west-002.backblazeb2.com',
    };
    this._storage = new S3Client(config);
  }

I think that we could add the option to specify an endpoint as part of the storage module config setup and then include it inside of the S3ClientConfig. This would allow S3 to be used with other S3 compatible storage providers.

Checklist

• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the Issue Tracker for a bug that matches the one I want to file, without success.
• This issue is not related to the Conduit Admin Panel user interface.

Conduit version

0.12.6

Describe the Bug

While the Database module is being brought up it checks whether the database it's attempting to connect to has previously been used with Conduit, otherwise it attempts to introspect it.

Specifically, it calls the active adapter's isConduitDb() function, which returns true in case there are Core schemas available.

This check will obviously fail on a fresh db, but that shouldn't initiate an introspection process on a non-populated database.

Thankfully, this won't crash right now, but it shouldn't be the case anyway.

Expected Behavior

On isConduitDb() === false, the Database module should actually check whether the database is devoid of any user generated collections before moving on with introspection.

How to Reproduce

1. Bring up Conduit with an unpopulated database.
2. Notice how the introspection process gets triggered.

Additional Information

No response

Environment

No response

Is your feature request related to a problem? Please describe.
Interfaces which include Email Provider specifications is a good feature that will enhance the email module.
For example , making interfaces which describe the templates of each provider would be a good idea.

Describe the solution you'd like
Each interface , should be extend the Template interface which already exists.
Template interface should also be modified.
So, it is necessary to find the common fields which are used to describe the templates among the providers.

Is your feature request related to a problem?
There is a major problem when authenticating with third party providers. 'Extra' details such as profile information
can't be stored in database. So ,the UserSchema must be transformed.

Describe the solution you'd like
Maybe a field like

data: Conduit.JSON

could solve this problem

Checklist

• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the Issue Tracker for a feature request that matches the one I want to file, without success.

Suggestion

When I have several clientids used in different places (eg. apollographql studio, postman, ci), I don't know which one to delete. When I have several clientids used in different places, I don't know which one to delete

Modules like Email, SMS and Storage depend either optionally or entirely on third party service providers.
Accessing and making use of said providers might not always be possible due to configured credentials being invalid, their service going down or even the backend user's account running low on credit.

Instead of just assuming a third-party dependent module is online as long as its configuration specifies active: true and it hasn't yet crashed, we should ideally be performing some checks to verify our connection is not only available, but also functional (that is to say, not connected, but unable to send emails due to a low credit block for instance).

These checks would also prove useful in notifying modules making use of a service-dependent module as to the latter's actual state.
For instance, Authentication's local authentication strategy makes optional use of Email for registration verification etc.
It's no good knowing that Email is online and "active" when in reality it could possibly be incapable of sending any emails.
This could also let us temporarily disable certain routes (route re-registration) on an inactive Email onConfig event and whatnot.

Describe the bug
RoutingManager sometimes ends up stringifying strings.
One instance of this is Chat's socket path ending up as /chat/"/".

Marking this for proper testing.

Describe the bug
Creating a new Schema takes longer than it should.

To Reproduce
Steps to reproduce the behavior:

1. Go to 'Database' tab
2. Click on 'Create Schema'
3. Fill the Schema fields and press save
4. See error

Expected behavior
Performing an action it may be normal to have a couple of seconds of delay but any longer than that and it should be considered a bug

Screenshots
If applicable, add screenshots to help explain your problem.

Environment (please complete the following information):

• Chrome 98 on a Windows 11 PC

Is your feature request related to a problem? Please describe.
Currently conduit spins up multiple containers that don't really make sense to be separate, since they can't practically scale independently. Email, push and sms utilise different external providers for their operations, but they fulfil a common goal of outgoing operations with templates etc.

Describe the solution you'd like
I think it'd be best for these to be merged into a singular "communications" module, that handles all outgoing user communications with either channel. This will allow for even cool things like "reach the user by any mean necessary", and incorporate more channels ex. viber, whatsapp etc.

Additional context
This particular module merge doesn't have any scalability arguments i think, since basically their capacity dependes 80-90% to the external services and merging them shouldn't provide any significant benefits or drawbacks on that part. But, it'd definitely save up some ram and cpu in the deployments.

Checklist

• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the Issue Tracker for a bug that matches the one I want to file, without success.
• This issue is not related to the Conduit Admin Panel user interface.

Conduit version

latest

Describe the Bug

make zero-to-hero

Initializing Conduit Container Environment 🔨
This may take a while. Better bring up Reddit 😅

make[2]: *** [Makefile:59: create-network] Error 1
make[1]: *** [Makefile:51: setup] Error 2
make: *** [Makefile:38: zero-to-hero] Error 2

Expected Behavior

should start services

How to Reproduce

1. mkdir conduit
2. cd conduit
3. source <(curl -s https://getconduit.dev/bootstrap)
4. make zero-to-setup

Additional Information

CMD

git bash

Environment

windows 10

Checklist

• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the Issue Tracker for a bug that matches the one I want to file, without success.
• This issue is not related to Conduit Admin Panel.
• This issue is not related to Conduit CLI.

Conduit version

0.15.15

Describe the Bug

If you try to configure github as OAuth provider in authentication/signIn and hit save, the configuration is applied to gitlab instead of github and vice versa.

Expected Behavior

Configuring github as OAuth provider should be applied to github and not gitlab and vice versa.

How to Reproduce

1. spin up your docker environment
2. sign in your app and goto Auth Providers
3. try to configure github
4. you will see, if you hit save, your configuration will be applied to gitlab

Additional Information

No response

Environment

No response

Checklist

• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the Issue Tracker for a bug that matches the one I want to file, without success.
• This issue is not related to the Conduit Admin Panel user interface.

Conduit version

0.14.0-0

Describe the Bug

The Form module does not appear in the active modules and fails to activate itself due to the user router not being initialised and therefore the form controller and the admin router not being instantiated. This happens after the removal of the "on" function which introduced callbacks (#220). The waitForExistence module method does not wait for the user router after it has been initialised resulting in the controller not working due to its dependency from the router.

Expected Behavior

The waitForExistence method should resolve when the routing module is up before other modules in order to initialise the user router for the forms module.

How to Reproduce

1. Spin up the Core,Database,Router and Email modules
2. Wait until all of them have finished initialising
3. Run the Forms module
4. Notice that the forms module fails to activate (TypeError: Cannot read properties of undefined (reading '_routingManager')

Additional Information

No response

Environment

No response

Is your feature request related to a problem? Please describe.
While I do love express, Fastify provides multiple utilities for better performance, it's more "current" and will allow us for better promise handling as well as validation.

Describe the solution you'd like
We need to do 2 main things. 1. Migrate all existing expressjs functionality to Fastify, and remove REST validation code and migrate it to fastify's built in JSON validation. This will be more performant and far more stable than the current implementation.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Checklist

• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the Issue Tracker for a feature request that matches the one I want to file, without success.

Suggestion

Modules' gRPC requests lack any sort of Conduit-specific protection against malicious requests.
Therefore it's currently entirely up to the end-users to secure their production deployment by cutting off access to their modules' gRPC servers for non-whitelisted connections.

We should ideally be protecting remote process calls on our end using some end-user specified key or something (eg GRPC_KEY).
We can't rely on Core's existing MASTER_KEY as getting that would depend on the modules communicating through gRPC anyway.

While gRPC requests are currently mostly performed by modules, they may also be manually used by administrators through the CLI, and possibly even the UI down the road, or even manually.

If we wish to keep track of which administrators are performing these requests we'll need to make use of admin tokens, possibly by generating/obtaining them through an rpc that's only protected using GRPC_KEY.

No matter what form of key/token combo we end up using, grpc-sdk is going to have to accommodate this added security layer.

Is your feature request related to a problem? Please describe.

Most deployments require some form of authentication.
In our case, that pretty much translates to having the Authentication module available.
Therefore, most users wishing to try out Conduit for the first time are most likely not going to be head over heels with the concept of spending much time on configuring it just so they can move on to finally giving the project a spin.

The module's initial configuration currently enables the "local" authentication strategy.
This is fairly convenient and greatly facilitates initial setup as it involves no third party providers.

The issue arises from "local" authentication defaulting to an email identifier, which results in Authentication full initialization effectively depending on either:

1. the user updating Authentication's config to make use of a username-based identifier
2. the Email module being available and properly configured

Option 1) requires a one-time administrative configuration request. Not too bad, until you consider how this affects our documentation and overcomplicates what would otherwise be fairly simple first timer tutorials.

Regarding 2), the problem is only magnified, as choosing to actually go with an email identifier not only requires that the Email module is brought online and configured, but also results in users having to possibly create an account at an email provider and specify all their creds in the module's configuration.
Unavoidable for actual deployments, but definitely overkill for trying out the project.

Describe the solution you'd like

The Authentication module should not depend on the Email module being configured nor available on initial run.
I can think of a couple different ways to achieve this.
Regardless of which one we end up going with, we should keep defaulting to the "local" authentication.

a) Have "local" auth strategy default to a "username" identifier. Extremely easy to do, but username auth is non ideal.

b) Keep defaulting to "email", switching off "sendVerificationEmail" and "verificationRequired", then only have Authentication actually wait on Email if said options are actually enabled so that the barebones "email" identifier does not actually depend on the Email module.

c) Keep the default config file as is, adding an env var to override the default identifier on a non-configured instance. Kinda needlessly complicated, plus the user is also going to be aware of the env var. What if they just launch Auth once without it and have the database store the "email" identifier config etc.

I'm leaning towards b).

Checklist

• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the Issue Tracker for a feature request that matches the one I want to file, without success.

Suggestion

I can't use S3 service normally in China.

If possible, add support for OSS services. Or I can consider writing the driver myself.

Checklist

• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the Issue Tracker for a bug that matches the one I want to file, without success.
• This issue is not related to Conduit Admin Panel.
• This issue is not related to Conduit CLI.

Conduit version

0.15.15

Describe the Bug

When a user is blocked from the admin panel, he can still call all endpoints (expect login) because the JWT is still active.

Expected Behavior

When a user is blocked, its associated JWT should be blacklisted.

How to Reproduce

1. Create a user
2. Login
3. Query a db document for example (it should work)
4. Block user
5. Query a db document for example (it SHOULDN'T work)

Additional Information

No response

Environment

No response

Checklist

• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the Issue Tracker for a feature request that matches the one I want to file, without success.

Suggestion

Opening this issue so as to document the way we currently approach user group related "add user" functionality and provide some suggestions on how we can improve on it for both existing and upcoming module features.

The limitation I'm about to describe is currently exclusively related to the Chat module's chat group feature, but should soon start affecting Authentication once its own user groups feature gets released.

As of right now, user authenticated application requests for creating a chat room and adding additional users to it unilaterally add target users to the group without any way for them to accept or decline this action.

While administrators should definitely be capable of operating in such a way, normal user requests should ideally be inviting other users to a group instead.
Automatically adding others into a group can not only end up being frustrating, depending on the app, but may also end up getting exploited by malicious users spamming such requests.
We would be retaining the existing functionality for apps that are best suited for it through a configuration option of course.

Adding users to a group, in the default configuration, should ideally send them an invitation for them to accept or decline.
We should also be sending out socket events for this so that client apps can pick these up in real time.

The very same considerations should be taken into account while implementing Authentication's user groups feature.

If we wish to take this up a notch at some point down the line we could make it so users' connections of sorts can be allowed to automatically add them to groups or even let users themselves configure their own preferences, but offering simple module configurations for it would be more than enough for most use cases and definitely not overkill.

Is your feature request related to a problem? Please describe.
Modules are currently written in a pretty chaotic way where initialization does not happen in an obvious or well defined order.

Describe the solution you'd like
Extend ConduitServiceModule with a class exposing lifecycle hooks for modules to use during initialization.
Said class should provide adequate options to cover any use case in regards to initialization order.

I can think of the following core initialization steps modules generally go through:

1. initialization (before registering with Core)
2. schema registration
3. activation

To cover any possible use case we should cover pre-target, target and post-target hooks for every(?) given step.
Example:

• pre_registerSchemas()
• registerSchemas()
• post_registerSchemas()

That way we get (optional) finer control over initialization while retaining the structure's self-descriptive nature.

While not strictly related to initialization, said class should probably also standardize configuration functions names (eg setConfig()).

Checklist

• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the Issue Tracker for a feature request that matches the one I want to file, without success.

Suggestion

when I use local storage provider, i can't get saved files. Neither base64 data nor url.

Checklist

• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the Issue Tracker for a bug that matches the one I want to file, without success.
• This issue is not related to Conduit Admin Panel.
• This issue is not related to Conduit CLI.

Conduit version

0.15.16

Describe the Bug

when sending an email with an SMTP setup (I am using Gmail), it fails with the following error code:
[ERROR]: Missing credentials for "PLAIN" Error: Missing credentials for "PLAIN"

smtp set up used is as follows:
Host: smtp.gmail.com
Port: 587
method: PLAIN

Expected Behavior

Email successfully sends

How to Reproduce

1. configure smtp with parameters described
2. send test email
3. observe

Additional Information

No response

Environment

Ubuntu 20.04 (LTS)

Describe the bug
Currently, the sequelize schema adds a default uuid (_id) as a primary key to the model. In case the user provides a database for introspection and the tables have already a primary key, there will be a conflict between that primary key and the _id we are trying to add to the schema.
We need to keep both ids though, since Conduit uses the _id for any queries related to that model.
One possible solution would be to change the _id from primary key to virtual, however sequelize currently doesn't support converting the virtual datatype into the sql equivalent (see sequelize/sequelize#12451).

To Reproduce

1. Start the database module with an existing database connection in the envs
2. Notice that the database won't sync because of the virtual field is not defined.

Expected Behavior
The database module should introspect the db by keeping both it's already defined primary key and adding the conduit _id used for future queries.

Is your feature request related to a problem? Please describe.
Currently conduit spins up multiple containers that don't really make sense to be separate, since they can't practically scale independently. Once such pair is CMS and Database. All CMS operations require the database and request increase in CMS is in a 1:1 relation with request increases in the Database.

Describe the solution you'd like
The proposal is to merge the 2 modules, and basically make all of the CMS functionality part of the database functionality.

Additional context
Something we should look out for is the breaking URL issues.

Describe the bug
While not necessarily breaking anything, Conduit should make sure its proto files abide by the official Protocol Buffers style guide.
I have yet to cross-check every single one of them, but at a first glance, it seems like we're mostly ignoring case conventions.
Namely snake_case for files (eg push-notifications.proto) and, sometimes, CamelCase for services and rpcs (eg Database's rpc findOne).

Expected behavior
Conduit's proto files should respect the official style guide, making sure they follow case conventions etc.