gemini-projects / gemini

Cloud Native and Low Code Platform to create FullStack web Admin applications in minutes

Cloud Native and Low Code Platform to create FullStack web Admin applications in minutes

---

✨ Features & Technologies

• REST API generator
  • Low Code CRUD & advanced filters/search APIs
  • Cloud Native and Serverless ready with Micronaut and GraalVM
  • Low code data storage drivers (define the schema and forget about anything else)
  • Customizable data drivers, for specific and custom use cases
• Full React Admin Single Page Application
  • Enterprise-class Antd architecture
  • Low Code ready to use Web App
  • Fully customizable with your own code and components
• Low code Full Stack React Components
  • Enterprise-class Antd components (Tables, Forms, etc...)
  • Ready to use in your existing projects in minutes

🏆 Top Use Cases

• Expose your data with solid REST APIs & OAuth2 without writing code
• Expose microservices data & boundaries
• Enterprise level BackOffice Web Application
  • For Internal usage (Admin Panels, Services Configuration, etc.)
  • For your clients, with ready to use full stack components
• Integrate full stack enterprise data components (tables, forms, etc..) in existing web applications
• Migration from Monolith to Cloud Native services and GUI

📄 Documentation

You can find the Gemini documentation on the official website.

Check out the Getting Started page for a quick overview.

Attention! Gemini is an under development platform. At the moment a full support service is guaranteed for companies who express interest in the project. If you want to try it out or use it in your company you we could get in touch on Linkedin.

✨ Who is using

Gemini.-.AIT.-.usecase.mp4

⚠️ Old Framework

In the last 2 year Gemini changed its architecture, from a Spring/Angular monolith approach to a Cloud Native and flexible one exploiting Micronaut and React. You can find the old framework on the old-0.5.0 branch

gemini's Issues

[OPENAPI] - Documentation files by module

Each Gemini module should provide its OpenAPI spec file in addition to the ALL spec.
RUNTIME became a special module and a special spec file.

[CORE/EntityManager]: Improve documentation and add EntityOperationContext to get APIs

EntityManager should be improved with better documentation. All the undocumented GET APIs should also add the EntityOperationContext in their signature to enable future use (like the other APIs).

[DSL-CORE-API]: Singleton Entity

A singleton Entity is a one record Entity, where we can only GET and PUT. No POST and DELETE are allowed. Todo:

• DSL new ENTITY Type
• CORE persistence and APIs (no delete or new one, only modify and get)
• Special API handling (no POST and DELETE)

[CORE-API] Entity Controller Method ALLOW/DISABLE

Need a way to avoid to bind unnecessary METHOD to Entity.

For example with singleton Entities of #1 the POST / DELETE method should be not allowed.

There is always a single record for that entity returned by the GET on entity root path (no need to have logical key).

[CORE-DSL] Closed Domain Entities not well handled by Gemini Startup

Need to move the closedDomain configuration in DSL or another settings. Or change the initschema handler.

[OPENAPI]: Parametric Info

Using the feature implemented in #1 make the openapi documentation info configurable.

In a singleton entity put all the information needed and the refactor the default.

[CORE] EntityReferenceRecord - Add actual record

Add also the actual record if exist.
Now we have only PK and LogicalKey references. If the Reference is created with a real EntityRecord we can store it.

[AUTH-MODULE] RBAC: role based access control

Need a way to limit operations on APIs accordingly to User roles. TODO:

• define the model
• define a way to identify the user role and integrate with OAuth2

We could use different strategie here...

For example bind in some way the OAuth2 scope concept to one or some user role. Or handle the RBAC to work only inside the core Framewoek accordingly to the logged user role decoupling role/scope and access_token. This mean that no OAuth2 scope are used, instead all the logic is made by Gemini core by using user roles.

[CORE-API]: Introduce the HTTP PATCH method and separate PUT/PATCH semantic

REST design tells that PUT should be used for full replace (all fields) while PATCH is used to make changes to part of the resource.

Add PATCH to separate behavior?

[PERSISTENCE-POSTGRSQL]: integration test for Update Entity Storage

All the operations like ADD / DROP column and modify an already existent table must be checked with unit and integration tests.

[CORE] EntityOperationContext for EntityManger and APIs

The EntityOperationContext should be added to all the methods of EntityManager. API Controller then can inject for example the user to be added on meta record informations.

[OPENAPI]: Singleton Entity API doc update

Need to update the OpenAPI Spec generation for Singleton Entity of #1

[CORE-DSL-API/EntityManager] Ordered Logical Key for Entities

Entities can have multiple logical key but at the moment the is a lexicographic order. Need to specify the order on DSL and implement it in the Core Entity Manager and API Paths.

For example:
ENTITY MultipleLK {
TEXT lk *1
TEXT lk2 *2
NUMBER a
}

*1 and *2 give the order