amplication / amplication

Amplication brings order to the chaos of large-scale software development by creating Golden Paths for developers - streamlined workflows that drive consistency, enable high-quality code practices, simplify onboarding, and accelerate standardized delivery across teams.

Transform platform engineering with tailor-made live templates and service catalog 🚀

Introduction

Amplication enables you to quickly build, maintain, and scale backend services that embed your company’s best practices and standards.

With Amplication you can create your own live templates embedding your organization’s best practices and standards, to ensure consistency and compliance from the start. 

Leveraging AI-powered automation, Amplication will generate microservices in no time, with everything that is needed to support your business domain: APIs, data models, DTOs and more, allowing engineers to focus on business logic.

Now your live applications will be always up-to-date. Amplication automatically handles package updates, patches, and versioning, reducing technical debt and ensuring consistency across your services. 

Features

 

 

 

Usage

To get started with Amplication, the hosted version of the product can be used. You can get started immediately at app.amplication.com. After the login page, you will be guided through creating your first service. The website provides an overview of the application, additional information on the product and guides can be found in the docs.

Tutorials

• To-do application using Amplication and Angular
• To-do application using Amplication and React

Development

Alternatively, instead of using the hosted version of the product, Amplication can be run locally for code generation purposes or contributions - if so, please refer to our contributing section.

Pre-requisites

To be able to start development on Amplication, make sure that you have the following prerequisites installed:

• Node.js
• Docker
• Git

Running Amplication

Note It is also possible to start development with GitHub Codespaces, when navigating to < > Code, select Codespaces instead of Local. Click on either the +-sign or the Create codespace on master-button.

Amplication is using a monorepo architecture - powered by Nx Workspaces - where multiple applications and libraries exist in a single repository. To setup a local development environment the following steps can be followed:

BEFORE you run the following steps make sure:

1. You have typescript installed locally on you machine npm install -g typescript

2. You are using a supported node version (check engines node in the package.json)

3. You are using a supported npm version (check engines npm in the package.json)

4. You have docker installed and running on your machine

5. Clone the repository and install dependencies:

git clone https://github.com/amplication/amplication.git && cd amplication && npm install

2. Run the setup script, which takes care of installing dependencies, building packages, and setting up the workspace:

npm run setup:dev

3. Option 1: Running the required infrastructure - view infrastructure component logs

npm run docker:dev

3. Option 2: Running the required infrastructure - run the infrastructure components in background

npm run docker:dev -- -d

4. Apply database migrations

npm run db:migrate:deploy

5. To start developing, run one or more of the applications available under serve:[application] scripts of the package.json.

# running the server component
npm run serve:server

# running the client component
npm run serve:client

# running the data-service-generator component
npm run serve:dsg

# running the git-sync-manager component
npm run serve:git

# running the plugin-api component
npm run serve:plugins

Note In order to run the Amplication client properly, both the client and server need to be started by the npm run serve:[application] command, as well as an additional component for development on a specific component.

The development environment should now be set up. Additional information on the different application components can be found under packages/[application]/README.md file. Happy hacking! 👾

Resources

• Website overview of the product.
• Docs for comprehensive documentation.
• Blog for guides and technical comparisons.
• Discord for support and discussions with the community and the team.
• GitHub for source code, project board, issues, and pull requests.
• Twitter for the latest updates on the product and published blogs.
• YouTube for guides and technical talks.

Contributing

The majority of Amplication code is open-source. We are committed to a transparent development process and highly appreciate any contributions. Whether you are helping us fix bugs, proposing new features, improving our documentation or spreading the word - we would love to have you as a part of the Amplication community. Please refer to our contribution guidelines and code of conduct.

• Bug Report: If you see an error message or encounter an issue while using Amplication, please create a bug report.

• Feature Request: If you have an idea or if there is a capability that is missing and would make development easier and more robust, please submit a feature request.

• Documentation Request: If you're reading the Amplication docs and feel like you're missing something, please submit a documentation request.

Not sure where to start? Join our discord and we will help you get started!

Contributors

License

A large part of this project is licensed under the Apache 2.0 license. The only exception are the components under the ee (enterprise edition) directory, these are licensed under the Amplication Enterprise Edition license.

amplication's Issues

Testing module - complete spec

Decision table

open issues for discussion in next sessions

We should use this issue to track items for open discussion in any of the future sessions:

• How to create API endpoints for actions that are needed in screens. Should we automatically create the API with all the requested features? should these API be editable in the APIs section? should we use the same roles from the page on the API?

Docker Build Service

Client Generator

Spec: https://www.notion.so/amplication/Generating-Admin-UI-Code-8f2cb498da6d42f6ba3ff23ace030f3e

Try reveres dark mode

Expression Resolver

Add timeout to GitHub action

Currently, it times out after 6 hours. It should time out after 15 minutes.

Should we add built in fields for all new persistent entities?

When a user create a persistent entity, should we add built in fields?

id
createdAt
updatedAt

Create symbols

Prototyping

Use classes instead of json schema

@iddan
I think we should consider to use classes with validation attributes (like all other model classes) instead of using json schema for all json fields.

in the current scenario (entity field properties) where we are dealing with just simple fields the json schema works well. But looking ahead on the pages and other very complex structures that we use json for I think json schema wont be enough.

I assume that when we'll build the ui editor or any other block like Connector, we will anyway use classes to describe the object - so we may as well use the objects to validate the request and more.

what do you think?

The app list is not updated after creating a new app

Create a new app, the go back to the app list - the new app is not listed

API Page

Unique constraints should be case insensitive

Current the Unique Keys (e.g. EntityField,Name) are case sensitive and the user can create two fields with identical names with different casing (e.g. "AAA" and "aaa").

Entity Page - Server Side

App Versioning (build, rollback…)

Add more "amplication" purple

create Amplication letterhead

Schema Validation

When saving entity fields, or blocks, or pages we need to save a list of properties in a JSON field in the DB.
We should validate the JSON schema before we save it to the DB.
for example:
EntityField.Properties is a JSON field that holds the special properties for each dataType.
When data type is "Single Line Text" the properties should only include "Max Length"
When data type is "Whole Number" the properties should include "Min Value" and "Max value".

In order to do that we can use a JSON schema validation package

https://github.com/tdegrunt/jsonschema
https://github.com/ajv-validator/ajv
https://github.com/ebdrup/json-schema-benchmark

for each datatype we should have an hard-coded schema and use it both on the client side and server for validation and presentation.

REST API Connector and OpenAPI spec

I found this project with types for OpenAPI documents.
https://github.com/kogosoftwarellc/open-api/blob/master/packages/openapi-types/index.ts

Theoretically we could use these types to create and save the configurations for our REST API Connectors but there are few issues:

1. GraphQL will not allow Union Types in the Input and many of the OpenAPI types are Union types.
2. Our configuration includes several extra functional features like "context parameters", permissions and visibility per specific fields and more....

For the above reason, I suggest that we use our own types to create REST API Connectors and only in runtime or build time we will convert our types to OpenAPI schema.

@iddan, your thoughts pleases

UI - Roles

See the "Roles" page in Figma

Login out and Logging In With Another Account Doesn't update the Account

Entity Page - Roles & Permissions

Data Service Generator

Entities page - The properties panel is not updated when selecting a field

When you select a field for the first time the properties panel opened and all values are correct, but when you click on another field while the panel is already open, the values of the new fields does not updated and you still see the values of the previously selected field

DB migrations process and best practices

we need to set a process on how to use prisma migrations.
Too often we have conflicts and need to hack around it.
There are probably best practices that can help us.
We should also think of how to use it later down the road on production to update live DBs.

@iddan if you have any input please share

Pages screen +UI Editor - Phase 2 - Base Design

cannot resolve Entity.fields on Entities Page

remove Is Persistent from the UI

The field IsPersistent determine whether the entity represents a table in the DB or just a DTO.
This is actually done using to different types of "entities" in the UI - Entity and Structure.

When the user creates "Entity" the field IsPersistent equals True
When the user creates "Structure" the field IsPersistent equals False

Entity Page - Client Side (w/o preview)

Create Email Signatures

Pages screen + UI Editor - Phase 1 - Spec

"Name" Fields validation

Entities and Entity Fields have a Name and a Display Name.
The Display name is used for display purposes throughout the system. The Name field is used for code and reference purposes.
for example, when a developer wants to assign a value from the Last Name field to the First Name field he will use the Name property in the following way:
customer.FirstName = customer.LastName

We should add validation both on the server side and client side for the correct format.

1, Choose format to be used (no spaces, dots, and such). Is there any common format for such fields?
2. Implement this on the server side (decorators with regex on the model? in the service?both?)
3. Implement this on the client side

Add cache to GitHub action

https://help.github.com/en/actions/configuring-and-managing-workflows/caching-dependencies-to-speed-up-workflows#using-the-cache-action

Entity Fields - Complete Validations for all types

Prisma Generator

App Code Generator

UI - Entities Page - Option Set

@LeeAmp
I created a new page in Figma called "Option Set" with an example of how the UI should looks like when creating a new option set.
Please merge the functionality into the main Figma page

amplication.com website

App Generator

Convert the presentation with the new branding

App Publisher

Invalid Password throws an Error instead of just trigger the UI

Entity Permissions - Client Side

GraphQL naming conventions

We should revisit all mutations and queries in graphQL and rename then with the entity name first and then the actions.
Instead of
createEntityField or CreateOneEntityField
we should use
entityFieldCreate

Instead of
createOneEntityVersion
we should use
entityCreateVersion or entitySaveVersion

@iddan, I know that with graphQL it is usually recommended to use the action first, but i dont like it. What do you think?
See this post for more info
https://www.apollographql.com/blog/designing-graphql-mutations-e09de826ed97

Restructure server code - use a folder per module/feature

-- src
-- featureName (folder)
-- featureName.ts (model)
-- featureName.module.ts
-- featureName.service.ts
-- featureName.resolver.ts
-- DTO (folder)
-- featureDto1.ts
-- featureDto2.ts
-- featureDto3.ts

Try different shades of the palette

Split ResourceBasedAuth Decorator

@iddan, as per out talk -
please split the decorator and create two seperate decorators. suggested names:

InjectContextValue Decorator
ContextAuthorize Decorator

Entities Page - Behaivour

• The side panel should always stay open and visible.
• When creating a new Entity Field, all the properties on the screen should show a default value (e.g. max length)
• A text field should be available on the entity box to add new fields without using the side panel
  • the user clicks on the + sign
  • a textbox is shown on the entity box, while the side panel shows a "new field" state.
  • The user types in the field name and clicks on Enter (he can also use the side panel for full features)
  • The new field is created with default values
  • The focus remains on the textbox to allow the user to create more Fields
• when the user types in a new entity name, the display name should be automatically created with spaces based on CamelCase format.
  The same for entities, including Plural Display Name.
• the Name field should only be limited to a specific set of characters. no spaces, no dots, etc (TBD)