A gateway and service discovery system for “micro” services. A light weight Gateway that connects all of your data services, API’s and endpoints to a single easy-to-use URL. Based on the Rapid Application Development tools and processes, the Gateway is build to use our Business Logic Module services, or allow for open source or propreitary gateways to connect and auth through the core and data mesh for faster component based development.
Buildly-Core is designed to be a cornerstone component for cloud-native architectures, providing a versatile gateway and service discovery system for microservices. Our vision is to simplify the integration of data services, APIs, and endpoints, offering a lightweight and easy-to-use solution that connects them all through a single, accessible URL.
- Simplified Integration: Streamline the integration of diverse data services, APIs, and endpoints into a unified gateway, making it easier for developers to work with microservices.
- Lightweight and High Performance: Prioritize performance optimization to ensure that Buildy-Core remains lightweight and responsive even in high-traffic environments.
- Service Discovery: Implement robust service discovery mechanisms to enable dynamic service registration and discovery for microservices within the architecture.
- Security and Access Control: Implement security measures to protect against unauthorized access and ensure data and services are secure.
- Flexibility and Scalability: Design Buildly-Core to be flexible and scalable, accommodating future growth and evolving architectural needs.
- Documentation and Ease of Use: Provide comprehensive documentation and resources to make it easy for developers to understand and work with Buildy-Core.
- Community Support: Foster a supportive community where developers can collaborate, seek help, and share insights and best practices.
These instructions will get you a copy of the project up and running on your local machine for development and testing purposes. See deployment for notes on how to deploy the project on a live system.
- Docker version 19+
Build first the image:
docker-compose build # --no-cache to force dependencies installationTo run the webserver (go to 127.0.0.1:8080):
docker-compose up # -d for detachedUser: admin
Password: admin.
To run the webserver with pdb support:
docker-compose run --rm --service-ports buildlyTo run the tests without flake8:
docker-compose run --entrypoint '/usr/bin/env' --rm buildly bash scripts/run-tests.sh --keepdbTo run the tests like if it was CI with flake8:
docker-compose run --entrypoint '/usr/bin/env' --rm buildly bash scripts/run-tests.sh --ciSee pytest --help for more options.
The instructions in the next three subsections Configure the API authentication, Generating RSA keys, and Configuration will explain how to configure a Buildly Core instance to have it on a live system.
All clients interact with our API using the OAuth2 protocol. In order to configure it, go to admin/oauth2_provider/application/ and add a new application there.
For using JWT as authentication method, we need to configure public and private RSA keys.
The following commands will generate a public and private key. The private key will stay in Buildly and the public one will be supplied to microservices in order to verify the authenticity of the message:
$ openssl genrsa -out private.pem 2048
$ openssl rsa -in private.pem -outform PEM -pubout -out public.pemSpecify each parameter using -e, --env, and --env-file flags to set simple (non-array) environment variables to docker run. For example,
$ docker run -e MYVAR1 --env MYVAR2=foo \
--env-file ./env.list \
buildly/buildly:<version>The following tables list the configurable parameters of buildly and their default values.
| Parameter | Description | Default |
|---|---|---|
ALLOWED_HOSTS |
A list of strings representing the domain names the app can serve | [] |
CORS_ORIGIN_ALLOW_ALL |
If True, CORS_ORIGIN_WHITELIST is not used and all origins are accepted | False |
CORS_ORIGIN_WHITELIST |
A list of origins that are authorized to make cross-site HTTP requests | [] |
DEFAULT_ORG |
The first organization created in the database | `` |
SECRET_KEY |
Used to provide cryptographic signing, and should be set to a unique, unpredictable value | None |
SUPER_USER_PASSWORD |
Used to define the super user password when it's created for the first time | admin in Debug mode or None |
AUTO_APPROVE_USER |
If approval process is set to auto-approve users can automatically login without admin apprvoal | False |
| Parameter | Description | Default |
|---|---|---|
DATABASE_ENGINE |
The database backend to use. (postgresql, mysql, sqlite3 or oracle) |
`` |
DATABASE_NAME |
The name of the database to use | `` |
DATABASE_USER |
The username to use when connecting to the database | `` |
DATABASE_PASSWORD |
The password to use when connecting to the database | `` |
DATABASE_HOST |
The host to use when connecting to the database | `` |
DATABASE_PORT |
The port to use when connecting to the database | `` |
| Parameter | Description | Default |
|---|---|---|
ACCESS_TOKEN_EXPIRE_SECONDS |
The number of seconds an access token remains valid | 3600 |
JWT_ISSUER |
The name of the JWT issuer | `` |
JWT_PRIVATE_KEY_RSA_BUILDLY |
The private RSA KEY | `` |
JWT_PUBLIC_KEY_RSA_BUILDLY |
The public RSA KEY | `` |
OAUTH_CLIENT_ID |
Used in combination with OAUTH_CLIENT_SECRET to create OAuth2 password grant | None |
OAUTH_CLIENT_SECRET |
Used in combination with OAUTH_CLIENT_ID to create OAuth2 password grant | None |
PASSWORD_MINIMUM_LENGTH |
The minimum length of passwords | 6 |
USE_PASSWORD_MINIMUM_LENGTH_VALIDATOR |
Checks whether the password meets a minimum length | True |
USE_PASSWORD_USER_ATTRIBUTE_SIMILARITY_VALIDATOR |
Checks the similarity between the password and a set of attributes of the user | True |
USE_PASSWORD_COMMON_VALIDATOR |
Checks whether the password occurs in a list of common passwords | True |
USE_PASSWORD_NUMERIC_VALIDATOR |
Checks whether the password isn’t entirely numeric | True |
SOCIAL_AUTH_GITHUB_REDIRECT_URL |
The redirect URL for GitHub Social auth | None |
SOCIAL_AUTH_GOOGLE_OAUTH2_REDIRECT_URL |
The redirect URL for Google Social auth | None |
SOCIAL_AUTH_LOGIN_REDIRECT_URL |
Redirect the user once the auth process ended successfully | None |
SOCIAL_AUTH_MICROSOFT_GRAPH_REDIRECT_URL |
The redirect URL for Microsoft graph Social auth | None |
| Parameter | Description | Default |
|---|---|---|
LDAP_ENABLE |
If true, enable LDAP authentication | False |
LDAP_HOST |
The host to use when connecting to the LDAP server | `` |
LDAP_USERNAME |
The username to use when connecting to the LDAP server | `` |
LDAP_PASSWORD |
The password to use when connecting to the LDAP server | `` |
LDAP_BASE_DN |
The base domain name for search | `` |
LDAP_USERNAME_FIELD_SEARCH |
The username field used by the LDAP server for search | `` |
| Parameter | Description | Default |
|---|---|---|
EMAIL_BACKEND |
If SMTP, enable connection to an SMTP Server |
`` |
EMAIL_HOST |
The host to use for sending email server | `` |
EMAIL_HOST_USER |
The username to use when connecting to the SMTP server | `` |
EMAIL_HOST_PASSWORD |
The password to use when connecting to the SMTP server | `` |
EMAIL_PORT |
The port to use when connecting to the SMTP Server | 587 |
EMAIL_USE_TLS |
Whether to use a TLS connection when talking to the SMTP server | True |
EMAIL_SUBJECT_PREFIX |
Subject-line prefix for email messages sent | `` |
DEFAULT_FROM_EMAIL |
The email address to be set in messages' FROM | `` |
DEFAULT_REPLYTO_EMAIL |
The email address to be set in messages' REPLY TO | `` |
- Travis CI - Recommended CI/CD
Please read CONTRIBUTING.md for details on our code of conduct, and the process for submitting pull requests to us.
We use SemVer for versioning. For the versions available, see the tags on this repository.
- Buildly - Initial work
See also the list of contributors who participated in this project.
This project is licensed under the GPL v3 License - see the LICENSE file for details.