Build a web service without a framework

The best test of whether a language holds up for real work is whether you can build a functioning web service with it without pulling in a framework from outside. In Norscode everything you need is in the standard library.

A route is a function

A web service in Norscode is functions that respond to requests. You mark a function with a route — for example GET / — read what you need from the request, and build a response with a status code and some content. There is no more ceremony than that.

The same tool runs it

When the service is written, you start it with nc serve. No separate server to set up alongside, no extra layer to learn. The same nc that checked and ran your code now takes in traffic.

Safe from the first request

A web service is precisely the kind of program you want to keep on a short leash: it talks to the world. This is where the capability model comes in handy — the service reaches only what you have given it, whether that is a folder of data or a specific host. Should something in the code try to do more, the runtime stops it.

The website you are reading this on

Norscode.no is itself a Norscode web service, built on the same standard library — the routes, the database and the markdown processing. It is not a stunt; it is the point. The tool should hold up for real work right out of the box, and a website that runs itself is a decent way to show it.

Read what the user sends

A route is rarely entirely static — it usually wants to read something from the request. You do that with the request_* functions from std.web, for example a query-string parameter:

la navn = web.request_query_param(ctx, "navn")
hvis navn == "" { navn = "verden" }

In the same way, there are functions for headers, cookies, the request body and which HTTP method was used. The response you build with response_builder, where you specify the status code, headers and content.

Safe by virtue of the runtime

A web service talks to the world, and is precisely the kind of program you want to keep on a short leash. This is where capabilities come in handy: the service does not bind a port without net.tcp, and it does not reach the disk unless you have given it access — limited to the folders you specify. Should a dependency try to do more, the runtime stops it.

From one file to production

When the service works locally, the path to production is short: the same file, the same nc serve, on a server. No separate application server to set up alongside. The website you are reading this on runs in exactly this way.

Back to the overview