What are front end canisters?

General
1

i have heard this term front end canisters but i don’t know what it means and what is the difference between a back end canister and front end canister

1 Like
2

Hi revoltez

You can write a frontend interface for an application you deploy on the Internet Computer using web frameworks like React, a frontend canister in your project contains this code, along with any images and static assets that need to be loaded in a visitor’s web browser.

A backend canister contains the code that will be executed on the Internet Computer itself, this is where your application persists data, for example. Your frontend code can make calls to your backend canister to query or update this data.

If you run dfx new my_project it’ll create a project with two canisters for you, the one called my_project_assets is the frontend canister, the one called my_project is the backend canister.

The tutorials include some good examples of how to do this, eg: Customize the front-end :: Internet Computer

5 Likes
3

thank you so much, this is brilliant its just like traditional code with canisters

2 Likes
4

I put together a very simple demo for a CRUD-style app written in only 500 lines of JavaScript and 100 lines of Motoko. Def worth checking out if you’re looking for something simple to get started with.

If you wanna see something more complex, then checkout this cool blog post:

4 Likes
5

One note - we currently have a limitation that your assets must be bundled into a single JavaScript file, totaling less than 2mb, and you can’t provide your own index.html.

This isn’t a hard technical constraint for a canister, but it is a feature that we intend to build out further once our other top launch priorities are addressed.

3 Likes
6

I REALLY look forward to being able to specify my own index.html, and to be able to have http paths resolve to canister functions. Without this, we can’t use http2/3 with JavaScript imports, can’t use dynamic imports, and can’t do things like host RSS feeds easily

2 Likes
7

@kpeacock . I wanted to ask you, does this limitation still exist?

8

These limitations are gone now! You can serve completely arbitrary content via raw.ic0.app, or you can load content via a serviceworker at ic0.app.

Here is my writeup on the new canisters
https://kyle-peacock.com/blog/dfinity/http-canisters

3 Likes
9

Hey @kpeacock . Thanks for the link :slight_smile:. Your write up is very good.

I have another question with regards to this.

As in the question at the link below, I was trying my hand at having multiple front end entry points within the same project.

The frontend canister and entry point setup would be as follows:
assets → index.html
second_assets → index2.html

Is something like this technically possible with Webpack?

10

Yes it is, but you’ll be getting into some more advanced and custom use cases. If you have fewer than 5 entry points, consider using multiple webpack configuration files or using environment variables to customize each job.

Otherwise, look at the webpack documentation around multiple entry points

1 Like
11

Is it possible to have one canister for both, front-end and back-end? Or do they always need to be on two separate canisters?

12

Yes you can, however you will need to implement http part yourself (check internet identity canister or custom implementation of http_request function). In general once you have http_request function in your canister you can create any kind of HTTP response.

In motoko function looks like this:

(this is part of icpunks nft standard)

    public query func http_request(request: HttpRequest) : async HttpResponse {
        let path = Iter.toArray(Text.tokens(request.url, #text("/")));

        var response_code: Nat16 = 200;
        var body = Blob.fromArray([]);
        var headers: [(Text, Text)] = [];

        if (path.size() == 0) {
            response_code := 404;
        } else {
            let asset = assetMap_.get(request.url);

            switch (asset) {
                case (?asset) {
                    body := asset.data[0];
                    headers := [("Content-Type", asset.contentType)];
                };
                case (_) {
                    response_code := 404;
                }
            };
        };


        return {
            body = body;
            headers = headers;
            status_code = response_code;
            streaming_strategy = null;
        };
    };

As in the example you can serve any valid response_code and content_type. (For example you could return JSON instead of html or image). Additionaly you can specify return headers so your options are really big.

2 Likes
13

This is true! It’s pretty easy to get a simple http_request set up, but it is pretty challenging to set it up with serving certified assets, which are required to deliver the asset via ic0.app.

2 Likes
14

Hello,

I deployed my first canister and I just realized the difference in the url between the one ending with raw.ic0.app and the one ending with .ic0.app
I must say that after trying to understand the difference, I can’t really evaluate the security impact of serving a public page (without login) that builds with data from a backend canister with either form. Moreover, if as I could read on the forum it is not safe or certified ? Why is this form (raw) is available?

My questions:

  • If the form raw.ic0.app is not safe how do I block it ?
  • In my application, I have a simple query API http_request that returns JSON which only works with the form raw.ic0.app and Kyle’s sentence implies that it is chalenging. I couldn’t find an explanation of the difference and impacts between these url forms?

Could someone kindly point me to an explanation that fits the current situation. What do I need to do to provide a reasonably secure application ?

Many thank for your clarifications