Skip to content

Commit

Permalink
chore: add post
Browse files Browse the repository at this point in the history
  • Loading branch information
aralroca committed Nov 4, 2024
1 parent 675b9b8 commit 059ebc2
Show file tree
Hide file tree
Showing 2 changed files with 83 additions and 3 deletions.
80 changes: 80 additions & 0 deletions packages/www/src/posts/brisa-0.1.4.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,80 @@
---
title: "Brisa 0.1.4"
created: 11/04/2024
description: "Brisa release notes for version 0.1.4"
author: Aral Roca
author_site: https://x.com/aralroca
---

This release has been based mainly on fixing bugs. This release fixes 11 bugs. Thanks to all contibutors:

- [@gustavocadev](https://github.com/gustavocadev)
- [@aralroca](https://github.com/aralroca)

## Improve req/sec 575%

In this version, we have improved the request per second by 575%. This improvement is due to the optimization of the server and the build process .The best thing is that there is still a lot of room for improvement. This is just a first step.

**Before**

```sh
> wrk -t12 -c400 -d30s http://localhost:3000
Running 30s test @ http://localhost:3000
12 threads and 400 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 100.81ms 11.35ms 199.92ms 88.45%
Req/Sec 328.18 28.23 510.00 89.02%
117868 requests in 30.09s, 47.89MB read
Requests/sec: 3917.06
Transfer/sec: 1.59MB
```

**Now**

```sh
> wrk -t12 -c400 -d30s http://localhost:3000
Running 30s test @ http://localhost:3000
12 threads and 400 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 14.82ms 4.45ms 59.72ms 95.47%
Req/Sec 2.28k 210.97 2.58k 86.69%
816361 requests in 30.02s, 331.66MB read
Requests/sec: 27198.12
Transfer/sec: 11.05MB
```

## Windows compatibility

In this version, we have fixed some bugs related to Windows compatibility during build process.

## More run-time agnostic

We are preparing Brisa to be more run-time agnostic. This is a first step to make Brisa compatible with other run-times like Cloudflare, Edge and Deno.

## Fix regression on Server Action without JavaScript

We have fixed a regression using [Server Actions](https://brisa.build/building-your-application/data-management/server-actions) on forms when the user has disabled JavaScript. Now is working again.

**And more...**

## What's Changed

- **test**: add test updating signal from multi-calls in effect – [@aralroca](https://github.com/aralroca) in [#590](https://github.com/brisa-build/brisa/pull/590)
- **fix(playground)**: fix back navigation on playground – [@aralroca](https://github.com/aralroca) in [#592](https://github.com/brisa-build/brisa/pull/592)
- **fix(file-system-router)**: fix regex to work on windows – [@aralroca](https://github.com/aralroca) in [#593](https://github.com/brisa-build/brisa/pull/593)
- **fix(cloudflare)**: remove WASM and replace hash to version – [@aralroca](https://github.com/aralroca) in [#594](https://github.com/brisa-build/brisa/pull/594)
- **fix(regression)**: solve indicator to work server action without js – [@aralroca](https://github.com/aralroca) in [#597](https://github.com/brisa-build/brisa/pull/597)
- **chore**: upgrade bun & dependencies – [@aralroca](https://github.com/aralroca) in [#598](https://github.com/brisa-build/brisa/pull/598)
- **fix(serve)**: fix prerender home page – [@aralroca](https://github.com/aralroca) in [#602](https://github.com/brisa-build/brisa/pull/602)
- **fix(windows)**: fix build error with unnormalized brisa dir – [@aralroca](https://github.com/aralroca) in [#603](https://github.com/brisa-build/brisa/pull/603)
- **perf(optimization)**: improve req/sec 575% – [@aralroca](https://github.com/aralroca) in [#604](https://github.com/brisa-build/brisa/pull/604)
- **fix**: solve regex in windows to fix build process – [@aralroca](https://github.com/aralroca) in [#605](https://github.com/brisa-build/brisa/pull/605)
- **fix(windows)**: fix `routeName` check in Windows – [@aralroca](https://github.com/aralroca) and [@gustavocadev](https://github.com/gustavocadev) in [#606](https://github.com/brisa-build/brisa/pull/606)
- **fix(dx)**: improve error feedback on CLI build – [@aralroca](https://github.com/aralroca) in [#607](https://github.com/brisa-build/brisa/pull/607)
- **fix(cloudflare)**: fix process.argv[1] for cloudflare adapter – [@aralroca](https://github.com/aralroca) in [#608](https://github.com/brisa-build/brisa/pull/608)

## New Contributors

- [@gustavocadev](https://github.com/gustavocadev) made their first contribution in [#606](https://github.com/brisa-build/brisa/pull/606)

**Full Changelog**: [https://github.com/brisa-build/brisa/compare/0.1.3...0.1.4](https://github.com/brisa-build/brisa/compare/0.1.3...0.1.4)
6 changes: 3 additions & 3 deletions packages/www/src/public/content.json
Original file line number Diff line number Diff line change
Expand Up @@ -4015,7 +4015,7 @@
{
"id": "/building-your-application/deploying/docker#containerize-with-docker",
"title": "Containerize with Docker",
"text": "This guide assumes you already have Docker Desktop installed. Docker is a platform for packaging and running an application as a lightweight, portable container that encapsulates all the necessary dependencies. To containerize our application, we define a Dockerfile. This file contains a list of instructions to initialize the container, copy our local project files into it, install dependencies, and start the application. # Adjust BUN_VERSION as desired\nARG BUN_VERSION=1.1.33\nFROM oven/bun:${BUN_VERSION}-slim AS base\n\n# Brisa app lives here\nWORKDIR /app\n\n# Set production environment\nENV NODE_ENV=\"production\"\n\n# Throw-away build stage to reduce the size of the final image\nFROM base AS build\n\n# Install node modules\nCOPY --link bun.lockb package.json ./\nRUN bun install --ci\n\n# Copy Brisa application code\nCOPY --link . .\n\n# Build Brisa application\nRUN bun run build\n\n# Final stage for app image\nFROM base\n\n# Copy built Brisa application\nCOPY --from=build /app /app\n\n# Start the Brisa server on port 3000\nEXPOSE 3000\nCMD [ \"bun\", \"run\", \"start\" ] Now that you have your docker image, let's look at .dockerignore which has the same syntax as .gitignore; here, you need to specify the files/directories that must not go in any stage of the docker build. An example of a ignore file is: dockerignore: .vscode\nnode_modules\n.DS_Store\nbuild If you want to be more strict, you can also invert the .dockerignore and use it as an allowed file. An example of how this would work is: dockerignore: # Ignore all files from your repo\n*\n\n# Allow specific files or folders\n!bun.lockb\n!package.json\n!src Making the .dockerignore an allowed file becomes very handy to prevent trash on your image, or sensitive information. For example secrets, coverage files or another dev on your team using a different IDE. We'll now use docker build to convert this Dockerfile into a Docker image. The result will be a self-contained template containing all the dependencies and configurations required to run the application on any platform. docker build -t my-app . The -t flag lets us specify a name for the image. We've built a new Docker image. Now let's use that image to spin up an actual, running container. docker run -p 3000:3000 my-app We'll use docker run to start a new container using the my-app image. We'll map the container's port 3000 to our local machine's port 3000 (-p 3000:3000). The run command prints a string representing the container ID. The container is now running in the background. Visit localhost:3000. You should see your homepage. Optional: the flag -d flag to run in detached mode to run the container in the background. To stop the container, we'll use docker stop <container-id>. If you can't find the container ID, you can use docker ps to list all running containers. That's it! Refer to the Docker documentation for more advanced usage.",
"text": "This guide assumes you already have Docker Desktop installed. Docker is a platform for packaging and running an application as a lightweight, portable container that encapsulates all the necessary dependencies. To containerize our application, we define a Dockerfile. This file contains a list of instructions to initialize the container, copy our local project files into it, install dependencies, and start the application. # Adjust BUN_VERSION as desired\nARG BUN_VERSION=1.1.34\nFROM oven/bun:${BUN_VERSION}-slim AS base\n\n# Brisa app lives here\nWORKDIR /app\n\n# Set production environment\nENV NODE_ENV=\"production\"\n\n# Throw-away build stage to reduce the size of the final image\nFROM base AS build\n\n# Install node modules\nCOPY --link bun.lockb package.json ./\nRUN bun install --ci\n\n# Copy Brisa application code\nCOPY --link . .\n\n# Build Brisa application\nRUN bun run build\n\n# Final stage for app image\nFROM base\n\n# Copy built Brisa application\nCOPY --from=build /app /app\n\n# Start the Brisa server on port 3000\nEXPOSE 3000\nCMD [ \"bun\", \"run\", \"start\" ] Now that you have your docker image, let's look at .dockerignore which has the same syntax as .gitignore; here, you need to specify the files/directories that must not go in any stage of the docker build. An example of a ignore file is: dockerignore: .vscode\nnode_modules\n.DS_Store\nbuild If you want to be more strict, you can also invert the .dockerignore and use it as an allowed file. An example of how this would work is: dockerignore: # Ignore all files from your repo\n*\n\n# Allow specific files or folders\n!bun.lockb\n!package.json\n!src Making the .dockerignore an allowed file becomes very handy to prevent trash on your image, or sensitive information. For example secrets, coverage files or another dev on your team using a different IDE. We'll now use docker build to convert this Dockerfile into a Docker image. The result will be a self-contained template containing all the dependencies and configurations required to run the application on any platform. docker build -t my-app . The -t flag lets us specify a name for the image. We've built a new Docker image. Now let's use that image to spin up an actual, running container. docker run -p 3000:3000 my-app We'll use docker run to start a new container using the my-app image. We'll map the container's port 3000 to our local machine's port 3000 (-p 3000:3000). The run command prints a string representing the container ID. The container is now running in the background. Visit localhost:3000. You should see your homepage. Optional: the flag -d flag to run in detached mode to run the container in the background. To stop the container, we'll use docker stop <container-id>. If you can't find the container ID, you can use docker ps to list all running containers. That's it! Refer to the Docker documentation for more advanced usage.",
"titles": [
"Docker"
]
Expand Down Expand Up @@ -4130,7 +4130,7 @@
{
"id": "/building-your-application/deploying/writing-a-custom-adapter#writing-a-custom-adapter",
"title": "Writing a custom adapter",
"text": "Adapters are useful to don't write IaC code, just plug and play. In Brisa, we offer adapters for some Cloud Providers, but you can write your own and share it with the community. If an adapter for your preferred environment doesn't yet exist, you can build your own. We recommend looking at the source for an adapter to a platform similar to yours and copying it as a starting point. Feel free to contribute your adapter to the Brisa community by opening a pull request in the Brisa repository. Adapter packages implement the following API, which creates an Adapter: import type { Adapter } from 'brisa';\n\nexport default function yourAdapter(options) {\n\tconst adapter = {\n\t\tname: 'adapter-package-name',\n\t\tasync adapt({ BUILD_DIR, ROOT_DIR, CONFIG }, prerenderedRoutes) {\n\t\t\t// adapter implementation\n\t\t},\n\t} satisfies Adapter;\n\n\treturn adapter;\n} Both, name and adapt are required. export type Adapter = {\n /**\n * The name of the adapter.\n */\n name: string;\n /**\n * This function is called after Brisa has built your app.\n */\n adapt(\n brisaConstants: BrisaConstants,\n prerenderedRoutes?: Map<string, string[]>,\n ): void | Promise<void>;\n};",
"text": "Adapters are useful to don't write IaC code, just plug and play. In Brisa, we offer adapters for some Cloud Providers, but you can write your own and share it with the community. If an adapter for your preferred environment doesn't yet exist, you can build your own. We recommend looking at the source for an adapter to a platform similar to yours and copying it as a starting point. Feel free to contribute your adapter to the Brisa community by opening a pull request in the Brisa repository. Adapter packages implement the following API, which creates an Adapter: import type { Adapter } from \"brisa\";\n\nexport default function yourAdapter(options) {\n const adapter = {\n name: \"adapter-package-name\",\n async adapt({ BUILD_DIR, ROOT_DIR, CONFIG }, prerenderedRoutes) {\n // adapter implementation\n },\n } satisfies Adapter;\n\n return adapter;\n} Both, name and adapt are required. export type Adapter = {\n /**\n * The name of the adapter.\n */\n name: string;\n /**\n * This function is called after Brisa has built your app.\n */\n adapt(\n brisaConstants: BrisaConstants,\n prerenderedRoutes?: Map<string, string[]>,\n ): void | Promise<void>;\n};",
"titles": []
},
{
Expand Down Expand Up @@ -5987,4 +5987,4 @@
"Inspirations"
]
}
]
]

0 comments on commit 059ebc2

Please sign in to comment.