old Inkdrop Documentation
  • Getting Started
    • 🚀Getting Started
  • FAQ
    • 📃FAQ
  • Core Concepts
    • 🧱Resource
    • 🔗Connector
    • 📦Wrapper
    • 📋Sidebar
    • 👩‍💻Code and Deployment
    • ⚙️Overriding Properties with the Codebox
  • Ressources
    • S3 Bucket
    • Lambda Functions
    • IAM Roles
    • API Endpoint
    • Fargate
    • Dynamo DB
    • RDS
    • SQS
    • SNS
  • Custom Code
    • Validating your cloud architecture
Powered by GitBook
On this page
  • Type
  • Name
  • Properties
  • Inputs & Outputs
  • Validation
  1. Core Concepts

Resource

PreviousFAQNextConnector

Last updated 1 year ago

Resources are the core element composable in our UI. They all have a ,,, , and . A typical resource looks like this:

Type

The type defines which cloud resource is being represented by the resource. These are usually the name of the cloud service being configured.

The type is written just below the name in the properties sidebar. It can also be deduced of the icon above or the color of the resource.

The type defines which properties, inputs and outputs a resource has.

Name

This is how the resource will be named and referenced in the code. By default, the resource will have the name of its type followed by the number in which it was created.

Because this name is referenced in the code no spaces or special characters are allowed in the name.

Properties

Inputs & Outputs

Inputs are displayed on the left side of a resource, Outputs are displayed on the right.

They are used to inherit a property or set up a trigger for another resource. When connecting resources only resources with matching Input/Output pairs will be shown as possible connections.

Most of the time connections are optional configurations except when permissions are required.

Validation

The cloud is complex and providers require many properties and securities to ensure your architecture is up to spec. We already do the heavy lifting by setting defaults for many properties and simplifying the connection process, but there are still mistakes and oversights that can happen. This is why we validate each individual input you make to ensure we catch these errors as early as possible.

We do this with validation which can force behaviors and show warnings when certain resources might be misconfigured.

For now, we check the proposed infrastructure against local endpoints to ensure the architecture is valid. As issues arise we continuously develop tooltips and documentation to mitigate erroneous architectures. Tooltips can be seen by hovering either above the faulty property or the red invalid marker at the top right of a resource.

It is best practice to rename the resources for better legibility. Resources can be renamed by double-clicking the resource name or by clicking the pen icon.

Properties are found in the right sidebar. This is how you configure the behavior of your resource. Depending on the there will be 0-5 properties to configure. Each type has a to explain what each property does. If the properties are filled incorrectly the will show the error and provide feedback on how to fix it.

Note: The number of Properties are intentionally kept low, in some case limiting certain use cases. This can easily be circumvented by writing conventional Terraform code in the .

🧱
type
name
properties
validation
inputs & outputs
resource type
validation
A standard resource with name, input, output, and validation
Resource type below type icon and resource name
Example of properties of a queue
Inputs on the left, Outputs on the right
Highlight when connection is possible
Valid resource, invalid resource
documentation
code box