[go: nahoru, domu]

Skip to content

Commit

Permalink
Lg/design skeleton (dfinity#346)
Browse files Browse the repository at this point in the history
* design apps section

* Preliminary draft ideas for design apps
  • Loading branch information
lsgunnlsgunn committed Mar 5, 2021
1 parent 3ccd17f commit feb478d
Show file tree
Hide file tree
Showing 2 changed files with 36 additions and 1 deletion.
2 changes: 1 addition & 1 deletion modules/ROOT/nav.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -16,7 +16,7 @@
.xref:developers-guide:sdk-guide.adoc[How to]
** xref:developers-guide:install-upgrade-remove.adoc[Install, upgrade, or remove software]
//xref:developer-guide:connect-network.adoc[Connect to a network]
** xref:developers-guide:customize-projects.adoc[Design apps]
** xref:developers-guide:design-apps.adoc[Design apps]
** xref:developers-guide:customize-projects.adoc[Manage projects]
** xref:developers-guide:work-with-languages.adoc[Develop using different languages]
//*** xref:language-guide:at-a-glance.adoc[Motoko]
Expand Down
35 changes: 35 additions & 0 deletions modules/developers-guide/pages/design-apps.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,35 @@
= Design apps
:proglang: Motoko
:platform: Internet Computer platform
:IC: Internet Computer
:company-id: DFINITY
:sdk-short-name: DFINITY Canister SDK


As you come up with ideas for applications, you are going to make many design decisions about how to structure and organize your project.
Most of these design decisions are independent of whether you you deploy your app on a traditional cloud service on the {IC}.
However, if you are going to deploy on the {IC}, there are a few design decisions that you should pay particular attention to as you plan the implementation for your app.

== Single or multiple canister architecture

One of the first decisions you might want to consider when designing your application is whether it should be encapsulated in a single canister or consist of multiple canisters.

For example, if you are writing a simple service with no front-end, you might want to use a single canister to simplify project management and maintenance and focus on adding features.
If your application has both front-end assets and back-end business logic, your project is likely to consist of at least two canisters, with one canister for managing user interface components and another canister for the backend services the application provides.

In planning, you might also consider placing some common reusable services in their own canister so that they can be imported and called from other more-specialized canisters or made available for other developers to use.
The link:https://github.com/dfinity/linkedup[LinkedUp] sample application illustrates this approach by splitting the professional service application into two canisters.
In the LinkedUp example, the functions that establish social connections are defined in the `connectd` canister and separate from the functions used to set up professional profiles that are defined in the `linkedup` canister.
It is easy to imagine extending the application with a third canister, for example to schedule events based on profile attributes or shared connections.

== Segregating actors from types and utilities


== Using query calls


== Data storage and retrieval

For many applications, databases are primarily used to provide long term storage of records that can be retrieved efficiently using one or more key fields. On the {IC}, this use case is usually addressed through data structures like hash tables.
Instead of a traditional database, the {IC} enables you to use *stable memory* to handle long-term data storage—often referred to as orthogonal persistance—and to use *query calls* to retrieve your data.
Although this approach works for most applications and simple key value database requests it doesn’t fully emulate a relational database.

0 comments on commit feb478d

Please sign in to comment.