{"posts":[{"creationDate":"2021-07-03T20:00:00.000Z","title":"Hasura Login + Docker","subHeader":"A custom login handler for Hasura. Combined with docker.","slug":"hasura-login-docker","blogImage":"/uploads/pexels_panumas_nikhomkhai_1148820_aab2c59d97.jpg","authorImage":"/uploads/coding_Bits_4c63b886dc.png","author":"Nils","html":"## Why Hasura?\n\nIn the last post series, I talked about ways to create a performant static website that can be edited easily via **Strapi** (a headless CMS). \n\nFor a lot of sites on the web, this is completely enough, but there are also services and websites or event phone Apps out there that need more than just static content but content that is created by its users or connects users. The most known platforms in that matter are Social Media platforms. \n\nIn the case of Social media, it is still possible to use tools like **Strapi** to create a website but it comes with disadvantages too. Its streamlined and easy way to create **Content-Types** can on the one hand make it way easier to create tables needed for an app but it also makes it harder to be more specific about the database types to choose from. In addition to that its graphQL implementation doesn't support subscriptions which makes it hard to create more dynamic real-time apps like a **Social Media** platform.\n\nThis is where **Hasura** comes into play.\n\n## What is Hasura\n\nHasura is a tool that can one or many **SQL** or **GraphQL** databases and automatically create a **GraphQL scheme** for it. In addition to this, it enables easy role and condition-based rights management that allows the integration of a lot of different authentification services to enable the login. In theory, this even enables the integration of an SQL Database used created by **Strapi** and uses **Strapi's** advantages while still handling role management on the front-end with **Hasura.** \n\n### In Short\n\nHasura transforms any SQL database into a real-time database with GraphQL and Role management capabilities.\n\n One of the bigger things that **Hasura** is missing however is an **Auth service**. There are plenty of tutorials online to use **Firebase Auth** or **Auth0** or any other existing Auth service to enable authentication. This however has the disadvantage that you are dependent on those services being around and keeping their costs low. In my experience, this is a dangerous bet to make. It is usually really hard to leave a service like Auth0 or Firebase and migrate your users to another system. And not only complicated but also often very inconvenient for the users.\n\nThis is exactly why this project came to be.\n\nI was experimenting with ways to use **Hasura** with an auth service that does not cost anything extra while still being secure.\n\nOnce I found I came to the following question: \n\nWhy not make this project portable and easy to use for anyone that needs it? (Or maybe I'll need it in future projects)\n\n# The Project\n\nIf you are experienced with **Hasura, node (express),** and **Docker** and decide that you won't need any info on how it is built you can just fork the [GitHub project](https://github.com/CodingBits1/hasuraLoginDocker) and use it however you want.\n\nIf you are still interested then I'm happy to go into detail.\n\n## Getting Started with Hasura\n\n**Hasura** offer its own already set up docker-compose file which we just need to run and set up. We will modify this to also add an **node (express)** server to run the custom login verification code in a docker alongside it. This way we can easily start both instances with one command.\n\nHow to use the dockerfile is explained in detail [here](https://hasura.io/docs/latest/graphql/core/getting-started/docker-simple.html#docker-simple).\n\nI'll summarize the necessary commands:\n\n```bash\n# create a new project\nmkdir hasuraLogin\ncd hasuraLogin\nwget https://hasura.io/docs/latest/graphql/core/getting-started/docker-simple.html#docker-simple\nsudo docker-compose up -d\nsudo docker ps\n```\n\nAfter the last command, there should be two active dockers listed in the terminal. **hasura/garphql-engin** and **postgress**. The first one is the **Hasura** engine that we are going to work with. The latter one is a **postgress** database that is used by **Hasura** to hold all the Hasura metadata and login data.\n\n![hasuraDocker1.png](/uploads/hasura_Docker1_711b82e720.png)\n\nIn this screenshot, you also see a container called **hasuralogindocker_node-login** container. This is the one we will be creating to add login capabilities to Hasura.\n\nOnce this is running we can access the Hasura admin pannel via [**http://localhost:8080/console](http://localhost:8080/console).**\n\n![hasuraDocker2.png](/uploads/hasura_Docker2_5470fbfd86.png)\n\nFor you, the queries should start empty which is the first thing we will have to change.\n\nWe will need to\n\n1. Create A User Table in the database to save and check our user\n2. Create a **SignUp** action that creates a new user in the database\n3. Create a **SignIn** action that checks the username and password in the database and if a matching pair is found sends back user info and a JWT token for authentification\n4. Set up permissions so the actions can be called from outside\n\nDoing those settings every time you set up a new instance of **Hasura** is tedious and prone to error. This is not necessary however since Hasura offers a CLI that allows to save the metadata and postgress migration files in a git and apply them whenever necessary. We will further go into those commands once we put everything together.\n\n## Creating a User Table\n\nTo do this we need to navigate to **Data** → **Create Table**\n\n![hasuraDocker3.png](/uploads/hasura_Docker3_0bac53047e.png)\n\n1. Fill in the **Users** as the title\n2. Create the necessary fields. It is especially important here to create a unique email and id field. The id will be generated automatically by setting **gen_random_uuid()** as the default value. This is a build-in function of Hasura.\nThe password needs to be a text since we are later generating a seeded and hashed value of the password here to add additional security for our users in case someone gets access to the database.\n3. We set the email as the primary key to make it easiest to search by email\n\n![hasuraDocker4.png](/uploads/hasura_Docker4_82c3c37e05.png)\n\n4. We add a regex constraint to ensure the email value to have the shape of an email.\n\n```bash\nemail ~* '^[A-Za-z0-9._%-]+@[A-Za-z0-9.-]+[.][A-Za-z]+$'::text\n```\n\nAfter that, we click on **Add Table**\n\n## Creating a Signup and SignIn Action\n\n**Hasura** helps you to create actions easily. First, we need to go to **Graphql** and enter the mutation into the query field:\n\n```graphql\nmutation SignUp($email: String, $name: String, $password: String) {\n insert_users_one(object: {email: $email, name: $name, password: $password}) {\n id\n }\n}\n```\n\nAfterward, we can click on **Derive Action** to let Hasura immediately give us some dummy code to base our action on\n\n![hasuraDocker5.png](/uploads/hasura_Docker5_5898a7bb88.png)\n\nOn this page, we will need to make two changes.\n\n1. Add an additional output field that will be used to allow the user to immediately log in after creating an account successfully\n2. Change the IP address of the handler from **[localhost](http://localhost)** to the local IP address of your computer.\nHow to find the IP addresses you can look [here](https://support.strongvpn.com/hc/en-us/articles/360003778933-How-To-Find-Your-Local-IP-Address-).\n\n![hasuraDocker6.png](/uploads/hasura_Docker6_81cc8c9de1.png)\n\nWe currently use the local IP address because docker's [localhost](http://localhost) address does not lead to the computer that runs docker. This has to be changed later when we create a docker container for the **node (express)** server as well.\n\nBut for development reasons we currently choose the local IP address.\n\nIn addition to changing the IP, we need to make sure the URL calls the right request **SignUp** instead of just accessing localhost:3000\n\nThe **Handler** should look something like this: **http:192.168.0.123:3000/SignUp.** \n\nAfter this, we can click on **Save** to create the action.\n\nIn the same way as before we can now create a **SignIn** Action. With the exception that this time it is going to be a **query** instead of a **mutation.**\n\n```graphql\nquery SignIn($email: String!) {\n users_by_pk(email: $email) {\n id\n }\n}\n```\n\nSince the query does not allow a password field we will have to add this in the action definition by hand.\n\n![hasuraDocker7.png](/uploads/hasura_Docker7_caf82571ea.png)\n\nAgain we need change the handler to **http:192.168.0.123:3000/SignIn** and ****hit **Save.**\n\n## Writing the login code\n\nNow that we have created two actions on the side of **Hasura** we need to write a rest API that does the signup logic, hashes the password, and sends back a signed JWT token to log the user in.\n\nFor this, we navigate to **Actions → SignUp → Codgen**.\n\nHere Hasura helps us by offering an initial boilerplate code for the express app as well as already preparing the Graphql mutation that the API needs to make to the server.\n\n![hasuraDocker8.png](/uploads/hasura_Docker8_199379d807.png)\n\nFirst, download the starter-kit.zip from the server and unzip it into a folder.\n\nIn there we need to open a terminal and run.\n\n```bash\nnpm install\nnpm install bcryptjs jsonwebtoken\nnpm run start\n```\n\nIn addition to starting the node server, we added two extra libraries **jsonwebtoken** and **bcryptjs**. The first one will be used to generate a JWT while the latter is used to hash the password safely before saving it in the database.\n\nAfterwards we can open a code editor and look at the code:\n\n```javascript\n//src/server.js\nconst express = require(\"express\");\nconst bodyParser = require(\"body-parser\");\n\nconst app = express();\n\nconst PORT = process.env.PORT || 3000;\n\napp.use(bodyParser.json());\n\napp.post('/hello', async (req, res) => {\n return res.json({\n hello: \"world\"\n });\n});\n\napp.listen(PORT);\n```\n\nThis is a simple express app that in its current state allows a user to make a request to **[https://localhost:3000/hello](https://localhost:3000/hello)** and get a JSON object back.\n\n```bash\n{ hello: \"world\" }\n```\n\nFor simplicity, I will keep all the code in one file for now. It is similar to the project I posted in Github except that the two actions are moved into separate files there.\n\n### Signup\n\nFor the **SignUp** we take the code from the codegen on the **Hasura** admin panel and apply it to the sever.js code.\n\n```javascript\nconst express = require(\"express\");\nconst bodyParser = require(\"body-parser\");\nconst fetch = require(\"node-fetch\")\nconst bcrypt = require(\"bcryptjs\");\nconst jwt = require(\"jsonwebtoken\");\n\nconst app = express();\n\nconst PORT = process.env.PORT || 3000;\n\napp.use(bodyParser.json());\n\napp.post('/hello', async (req, res) => {\n return res.json({\n hello: \"world\"\n });\n});\n\n// execute the parent operation in Hasura\nconst signup = async (variables) => {\n const HASURA_OPERATION = `\n mutation SignUp($email: String, $name: String, $password: String) {\n insert_users_one(object: {email: $email, name: $name, password: $password}) {\n id\n }\n }\n `;\n\n const fetchResponse = await fetch(\n \"http://localhost:8080/v1/graphql\",\n {\n method: 'POST',\n body: JSON.stringify({\n query: HASURA_OPERATION,\n variables\n })\n }\n );\n const data = await fetchResponse.json();\n console.log('DEBUG: ', data);\n return data;\n};\n \n\n// Request Handler\napp.post('/SignUp', async (req, res) => {\n\n // get request input\n const { email, name, password } = req.body.input;\n\n // run some business logic\n\n // execute the Hasura operation\n const { data, errors } = await signup({ email, name, password });\n\n // if Hasura operation errors, then throw error\n if (errors) {\n return res.status(400).json(errors[0])\n }\n\n // success\n return res.json({\n ...data.insert_users_one\n })\n\n});\n\napp.listen(PORT);\n```\n\nThis code is similar to the Hasura generated code with 3 exceptions.\n\n1. We Renamed the execute function to signup since we are going to add a **SignIn** function later as well\n2. We added two additional imports **bcrypt** and **jwt**\n3. We moved the **HASURA_OPERATION** into the signUp function (this is not the most efficient but for now it works)\n\nThis code now does the same thing as the Graphql **signup** mutation we created earlier. We need to modify the password to not be standing in cleartext but as a hashed value, as well as generate a JWT token so the user can SignIn after registration.\n\nWe will modify the Signup function to something like this: \n\n```javascript\n// Request Handler\napp.post('/SignUp', async (req, res) => {\n\n // get request input\n const { email, name, password } = req.body.input;\n\n // run some business logic\n\n // execute the Hasura operation\n let hashedPassword = await bcrypt.hash(password, 10)\n const { data, errors } = await signup({ email, name, hashedPassword });\n\n // if Hasura operation errors, then throw error\n if (errors) {\n return res.status(400).json(errors[0])\n }\n\n const tokenContents = {\n sub: data.insert_users_one.id.toString(),\n name: name,\n iat: Date.now() / 1000,\n iss: \"http://localhost/\",\n \"https://hasura.io/jwt/claims\": {\n \"x-hasura-allowed-roles\": [\"user\"],\n \"x-hasura-user-id\": data.insert_users_one.id.toString(),\n \"x-hasura-default-role\": \"user\",\n \"x-hasura-role\": \"user\"\n },\n exp: Math.floor(Date.now() / 1000) + (24 * 60 * 60),\n }\n const token = jwt.sign(tokenContents, \"JWT_SECRET\")\n\n // success\n return res.json({\n id: data.insert_users_one.id,\n token\n })\n\n});\n```\n\nAfterward, we can save this and test our signUp Mutation in **Hasura.**\n\nTo test ist we open **Graphql** in the admin panel and enter\n\n```graphql\nmutation SignUp($email: String, $name: String, $password: String) {\n signup(email: \"test@email.com\", name: \"testName\", password: \"testPassword\")\n}\n```\n\nAfterward, this should respond with a randomly generated user id and a **JWT** token.\n\n### SignIn\n\nFor the sign, we similarly copy the code from **Hasura** via **Codegen** and modify it to test the login data and create a JWT\n\n```javascript\nconst signIn = async (variables) => {\n const HASURA_OPERATION = `\n query ($email:String!)\n {\n users_by_pk(email: $email) {\n email\n id\n name\n password\n }\n }\n `; \n\n const fetchResponse = await fetch(\n \"http://localhost:8080/v1/graphql\",\n {\n method: 'POST',\n body: JSON.stringify({\n query: HASURA_OPERATION,\n variables\n })\n }\n );\n const data = await fetchResponse.json();\n return data;\n};\n\napp.post('/SignIn', async (req, res) => {\n\n // get request input\n const { email, password } = req.body.input;\n let lcEmail = email.toLowerCase();\n\n // execute the Hasura operation\n const { data, errors } = await signIn({ email: lcEmail });\n\n // if Hasura operation errors, then throw error\n if (errors) {\n return res.status(400).json(errors[0])\n }\n \n let userData = data.users_by_pk; \n if (!userData){\n return notFoundError(res);\n }\n let passwordRight = await bcrypt.compareSync(userData.email.toLowerCase() + password, userData.password)\n \n if (!passwordRight) return notFoundError(res);\n \n const tokenContents = {\n sub: userData.id.toString(),\n name: userData.name,\n iat: Date.now() / 1000,\n iss: \"http://localhost/\",\n \"https://hasura.io/jwt/claims\": {\n \"x-hasura-allowed-roles\": [\"user\"],\n \"x-hasura-user-id\": userData.id.toString(),\n \"x-hasura-default-role\": \"user\",\n \"x-hasura-role\": \"user\"\n },\n exp: Math.floor(Date.now() / 1000) + (24 * 60 * 60),\n }\n \n const token = jwt.sign(tokenContents, \"JWT_SECRET\")\n\n // success\n console.log({\n id: userData.id,\n token\n })\n return res.json({\n id: userData.id,\n token\n })\n\n});\n\nfunction notFoundError(res){\n return res.status(401).json({\n message: \"Email or password wrong\",\n code: \"401\"\n });\n}\n```\n\nThe resulting code should look something like the above.\n\nWhich again can be tested by making a Graphql query in **Hasura:**\n\n```graphql\nquery MyQuery {\n signin(email: \"test@email.com\", password: \"testPassword\")\n}\n```\n\nThis should answer with the **UserID** of the above-created user as well as a **JWT** to sign the user in.\n\n## Handling secret keys and admin-secret\n\nIn this case, we didn't add any admin secret or changeable keys to the code. This is of course insecure and cannot be used in production in this state.\n\nI again encourage you to take a look at the [Github](https://github.com/CodingBits1/hasuraLoginDocker) Project where I used Environment variables that can be set in ****the docker-compose file to ensure the server and the node (express) app always use the right **Secrets**.\n\n## Creating a Docker Project\n\nNow that we have a working node server that handles the login as well as a working **Hasura** instance Its time to make it portable so it can, on one hand, be easy deployed to any production server, and on the other hand, be also easily clonable and used as a starting for any projects that needs a backend with a login.\n\nThe first thing we will need to do is move the nodejs project folder to the same folder we hold the **docker-compose.yaml.** in.\n\nThe Project should look something like this:\n\n![hasuraDocker9.png](/uploads/hasura_Docker9_4d385bb0e4.png)\n\nWith the **nodeLogin** being the node-server.\n\nIn the **nodeLogin** folder we will now create a file called **dockerfile** which will be used to automatically create and set up the node server in a docker environment.\n\nIn the dockerfile we have the following code\n\n```docker\nFROM ubuntu:18.04\n\nLABEL maintainer=\"codingBits\"\nLABEL version=\"0.1\"\nLABEL description=\"Node Server to handle login and signup of Hasura\"\n\nARG DEBIAN_FRONTEND=noninteractive\n\nRUN apt-get update\nRUN apt-get upgrade -y\nRUN apt-get install nodejs -y\nRUN apt-get install npm -y\n\nEXPOSE 3000\n\nCOPY . /root/nodeLogin\n\nWORKDIR /root/nodeLogin\nRUN pwd\nRUN rm -rf node_modules\nRUN npm install\n\nCMD [\"/usr/bin/npm\", \"run\", \"start\"]\n```\n\nA dockerfile is a file that is used to create a docker image, which then can be used to create a container and run it.\n\nThis file essentially \n\n1. creates a docker image based on **ubuntu 18.04**\n2. Installs **nodejs** and **npm**\n3. Exposes port 3000 to the outside\n4. copy the node server to the docker environment\n5. Installs the required node_modules packages\n6. Runs the start command once the image is loaded\n\nAfter this is created we can now add this file to the **docker-compose.yml** to create this image alongside **postgress** and **Hasura**.\n\nThe file will look something like this:\n\n```docker\nversion: '3.6'\nservices:\n postgres:\n image: postgres:12\n restart: always\n volumes:\n - db_data:/var/lib/postgresql/data\n environment:\n POSTGRES_PASSWORD: postgrespassword\n node-login: \n build: ./nodeLogin\n ports: \n - \"3000:3000\"\n environment: \n PORT: 3000\n HASURA_HOST: graphql-engine\n HASURA_SECRET: hasuraAdminSecret\n HASURA_PORT: 8080\n JWT_SECRET: \"HASURA_GRAPHQL_JWT_SECRET_WITH_AT_LEAST_32_CHARS\"\n graphql-engine:\n image: hasura/graphql-engine:v1.3.3\n ports:\n - \"8080:8080\"\n depends_on:\n - \"postgres\"\n - \"node-login\"\n restart: always\n environment:\n HASURA_GRAPHQL_DATABASE_URL: postgres://postgres:postgrespassword@postgres:5432/postgres\n ## enable the console served by server\n HASURA_GRAPHQL_ENABLE_CONSOLE: \"true\" # set to \"false\" to disable console\n ## enable debugging mode. It is recommended to disable this in production\n HASURA_GRAPHQL_DEV_MODE: \"true\"\n HASURA_GRAPHQL_ENABLED_LOG_TYPES: startup, http-log, webhook-log, websocket-log, query-log\n ## uncomment next line to set an admin secret\n HASURA_GRAPHQL_ADMIN_SECRET: hasuraAdminSecret\n HASURA_GRAPHQL_JWT_SECRET: '{\"type\":\"HS256\", \"key\": \"HASURA_GRAPHQL_JWT_SECRET_WITH_AT_LEAST_32_CHARS\"}'\n HASURA_GRAPHQL_UNAUTHORIZED_ROLE: 'public'\nvolumes:\n db_data:\n```\n\nThis did some amount of changes to the environment variables of **Hasura** as well as add the node node-image under **node-login.** \n\nHere we have to make sure we change variables like the **JWT_SECRET**, the **HASURA_GRAPHQL_ADMIN_SECRET**, **postgresspassword** so it cannot be guessed by users.\n\nThat information should be held confidential. And away from any user.\n\nOnce we are done developing we should also set **HASURA_GRAPHQL_ENABLE_CONSOLE** and **HASURA_GRAPHQL_DEV_MODE** to \"false\" since that increases the security by not exposing the admin access to any users.\n\n## Running the server\n\nOnce we are done we can run this by running \n\n```bash\nsudo docker-compose up --build -d\n```\n\nThis will not immediately work out of the box, however, since we still have to adjust the **Handler** URLs for the actions.\n\nThanks to the docker-compose we can now access the node server by a name instead of an IP.\n\nWe have to switch the IP address and the port to **node-login:3000**.\n\nThe **signUp** URL would for example look like **http://node-login:3000/SignUp**.\n\n## Saving the state of Hasura\n\nAs I already mentioned before, Hasura does not directly save its state. When moving to another server or another machine all the state is lost.\n\nThis can be prevented by the help of the **HasuraCLI** which allows you to save all **metadata** like the actions and the structure of the database with **migration** files.\n\nThose files can then be applied to a new running Hasura instance to make sure everything is in a working state.\n\nTo do this we will first need to install the **HasuraCLI** which can be done by following [this tutorial](https://hasura.io/docs/latest/graphql/core/hasura-cli/install-hasura-cli.html#install-hasura-cli) or by calling the following code in Linux.\n\n```bash\ncurl -L https://github.com/hasura/graphql-engine/raw/stable/cli/get.sh | bash\n```\n\nAfterward, we need to create a folder next to the **nodeLogin** folder called **Hasura** and copy the current state there. This can be done by following [this guide](https://hasura.io/docs/latest/graphql/core/migrations/migrations-setup.html) for the database and [this guide](https://hasura.io/docs/latest/graphql/core/migrations/manage-metadata.html) for the metadata, ****or running the following commands:\n\n```bash\nhasura init hasura --endpoint http://my-graphql.hasura.app\ncd hasura\nhasura migrate create --admin-secret 'hasuraAdminSecret'\nhasura metadata export --admin-secret 'hasuraAdminSecret'\n```\n\nAfterward, those data can be added to a git folder and applied automatically on another machine by running:\n\n```bash\nhasura migrate apply --admin-secret 'hasuraAdminSecret'\nhasura metadata apply --admin-secret 'hasuraAdminSecret'\n```\n\nIn the [Git Project](https://github.com/CodingBits1/hasuraLoginDocker) this is immediately applied when building the docker via the **[buildLocal.sh](http://buildlocal.sh)** script.\n\n## That's it!\n\nThat's it. This tutorial is skipping things like how to set up and use **Environment** variables in code since going too much in detail would be overkill for this already long post.\n\nThis is meant to give you enough information to take the [git project](https://github.com/CodingBits1/hasuraLoginDocker), fork it, and create any project you want. \n\nIt is not meant as a complete, secure backend for a huge system since this also needs additional safety like preventing users to call this API too often in a row. This can however be achieved via tools like **Nginx** by adding a rate limit to the login or signup request.\n\nThis project could however act as a quick starting point to prototype your next project using **Hasura** and **Graphql**. \n\nIf you see any improvements don't hesitate to contact me via Git or the contact form of this blog. I'll do my best to address them.\n\nThanks for reading.\n","authorUrl":"/about","tags":["Hasura","Jwt","Docker"]},{"creationDate":"2021-06-07T14:00:00.000Z","title":"Svelte, Strapi, Nginx (6)","subHeader":"Fetching Data and how to integrate Strapi with Svelte","slug":"svelte-strapi-nginx-6","blogImage":"/uploads/blog_Post_Dummy_Image_c98ea26879.jpg","authorImage":"/uploads/coding_Bits_4c63b886dc.png","author":"Nils","html":"In the last post, we talked about Strapi. How to set it up and how it can be useful over alternatives.\n\nToday we're building upon those result and learn how to integrate Strapi with Svelte\n\n# TLDR\n\nFirst we'll discuss how to modify our svelte app to fetch the data from the **Strapi** backend. Once this is set up we'll learn how to locally build a static website that can be uploaded to a static web-hoster.\n\nFor some people that are already enough for the ones that need more, we'll explain how to host the website more dynamically with the use of a Linux server. \n\nI'll also link tutorials on how to set up a domain and give examples on what servers can be used.\n\n# Fetching the data locally\n\nIn the previous Blogpost: [Svelte, Strapi, Nginx (3)](https://coding-bits.net/blog/svelte-strapi-nginx-3) we prepared the fetching of the data from an external source. Back then we didn't have an URL to fetch from since our backend did not exist. We simulate the fetching process with a fake delayed Promise. This can now be updated to the actual fetching function.\n\n```jsx\n//Fetch the data\nlet fetchUrl = \"http://localhost:1337/\"\n\nasync function fetchData(){\n\tlet result = new Promise( async (resolve, reject) => {\n\t\tfetch(fetchUrl + \"blog-posts\").then(async result => {\n\t\t\tresolve( await result.json() )\n\t\t})\n\t}\n\t\n\tupdateLookupData( await result )\n\treturn lookup;\n}\n```\n\nWe modified the fetch function to a promise that fetches the data from an external server specified via the fetch URL. \n\nAgain this fetching is not done by the user but by the server that runs your dynamic or builds your static website. This has some advantages and disadvantages compared to letting the user access the database directly. For the most part, this enables if done correctly to bring advantages of a static page to a dynamic page. This also enables together with sapper to use the backend only locally and build a static page locally. This enables to use of a static website hoster while still having some of an admin panel in the background.\n\nIn the next step this is exactly what I will show. It is not necessarily advised to offer this to a customer that is not very tech-savvy but this could be build upon to enable static server files for download to a customer that demands a static hosting service.\n\n# Building a static page Locally\n\nTo generate a static site from this you as discussed before you first have to run the start command for **Strapi** in its source folder\n\n```bash\ncd [strapi source folder]\nnpm run build\nnpm run start\n```\n\nAfterwards its time to build the website locally\n\nIf we run the following commands we will build the website and start it as a dynamic website\n\n```bash\ncd [svelte-blog source folder]\nnpm run build\nnpm run start\n```\n\nto actually render it statically we also need to run:\n\n```bash\nnpm run export\n```\n\nIn the folder **sapper/export** you can then find the code to be uploaded to a server.\n\nAs discussed before this could be used to rebuild the static page on a server whenever someone changes something of **Strapi**. This enables to offer a static website to a customer that he only needs to upload to the server whenever he wants to do changes. This can of course also be done programmatically if the hoster offers a CLI.\n\nFor most people, however, it is better to offer a dynamic website on a server. For this, it is advised to internally reroute the requests to certain ports instead of letting the user enter a port in an URL\n\n# Using Nginx to combine sapper and svelte on a Linux server\n\n## Linux Server\n\nTo enable the site to run on a Linux server we need to first install Nginx on a Linux server.\n\nI'm currently using **Digital** **Ocean** for this since it's pretty affordable and quick to set up. I've so far only had a good experience with it. If you are currently looking for a hoster and are interested in supporting me follow this [referral link](https://m.do.co/c/b7d4323394a1). \n\nThis will \n\n- Give you a 100$ worth in credits that can be used for 60-days free of charge to host your own server\n- Give me 25$ of credits if you use it further.\n\nFor a simple blog in the beginning a 10$ server should be enough.\n\nAny other virtual or dedicated server will do. For this tutorial I'll talk about the lineup server.\n\nAfter this, you will need to connect to your server via a terminal. In the case of **Digital Ocean**, they offer a terminal in the browser, but I would rather suggest using a command-line tool like **Putty** or **Git-Bash** on Windows, or the terminal on Linux or Mac to connect to the server via **SSH**.\n\nWe will later use **SSH** to deploy our files so it is advised to set this up. There are other ways to deploy your code but if you want to follow this tutorial then this is necessary.\n\nIn the case of **Digital Ocean** this is explained [here](https://docs.digitalocean.com/products/droplets/how-to/connect-with-ssh/).\n\nYou will also need a user with **sudo** access since it is not advised to run the commands as the root user.\nThis [tutorial](https://www.digitalocean.com/community/tutorials/how-to-create-a-new-sudo-enabled-user-on-ubuntu-18-04-quickstart) explains how to create one.\n\n## Getting a Domain\n\nAside from a server you will also need a Domain, to make your website easier to access.\n\nThis can be registered at any domain registrar like [Google Domains,](https://domains.google.com/registrar/) [GoDaddy](https://godaddy.com), or any other domain registrar. \n\nThen you will need to set the URL to the IP address of your server. This is explained in detail for various registrars at [this](https://www.digitalocean.com/community/tutorials/how-to-point-to-digitalocean-nameservers-from-common-domain-registrars) tutorial. \n\nOnce this is done we should also create a second subdomain to access the admin platform. This is further explained [here](https://docs.digitalocean.com/products/networking/dns/how-to/add-subdomain/).\n\nThe admin subdomain for now will be **admin.test.com** (amusing the URL is test.com).\n\n## What is Nginx\n\n\"NGINX is open source software for web serving, reverse proxying, caching, load balancing, media streaming, and more.\" (source [nginx doku](https://www.nginx.com/resources/glossary/nginx/)).\n\nIt is open-source software that takes requests from anywhere and redirects them to where they need to be. It looks at the query itself which allows directing certain queries to process A and others to process B.\nIt doesn't matter where this process is located, on a different port, a different server, or possibly a docker container. \nIn our case, this is needed since the user might access pictures and content data directly from **Strapi** while still requesting the same URL. It can also be seen as additional security because users only can access pictures from strapi while the rest will always go directly to the svelte app. To access the admin panel the user will need to know a separate subdomain,\n\n## Installing Nginx\n\nOnce this is done we are ready to set up **Nginx** a Firwall, and upload our code.\n\n```bash\nsudo apt update\nsudo apt install nginx ufw -y\nsudo ufw allow ssh\nsudo ufw allow 'Nginx Full'\n```\n\nThe installation status of nginx can then be checked via:\n\n```bash\nsudo systemctl status nginx\n```\n\nThe commands that involve **UFW** are to install a firewall to only allow certain ports to be accessed as a security precaution.\n\nThe next thing we will need to do is enable a Firewall to ensure that the others can only connect to ports they are allowed to access.\n\nAfter this we can start nginx via\n\n```bash\nsudo systemctl start nginx\n```\n\nor reload it in between changes that we are going to make via\n\n```bash\nsudo systemctl reload nginx\n```\n\n## Preparing Nginx for the Sapper frontend\n\nAfter all is installed we need to first set up the frontend and then the backend.\n\nFor the frontend, we need to create a new file at **/etc/nginx/sites-available** with the filename of our domain. Let's say the domain is **www.test.com**\n\nTo create it we run:\n\n```bash\ncd /etc/nginx/sites-available\nsudo nano www.test.com\n```\n\nAnd the we copy this code into the terminal editor\n\n```bash\nserver {\n\tserver_name test.com www.test.com;\n\n\tlocation /uploads {\n\t\tproxy_pass http://localhost:1337;\n\t\tproxy_http_version 1.1;\n\t\tproxy_set_header Upgrade $http_upgrade;\n\t\tproxy_set_header Connection 'upgrade';\n\t\tproxy_set_header Host $host;\n\t\tproxy_cache_bypass $http_upgrade;\n\t}\n\n\tlocation / {\n\t\tproxy_pass http://localhost:3000;\n\t\tproxy_http_version 1.1;\n\t\tproxy_set_header Upgrade $http_upgrade;\n\t\tproxy_set_header Connection 'upgrade';\n\t\tproxy_set_header Host $host;\n\t\tproxy_cache_bypass $http_upgrade;\n\t}\n}\n```\n\nThen to exit and save the file we just need to press **Ctrl-x** and then **Y**.\n\nThis code does 2 things\n\n- It reroutes every call to **test.com** or **www.test.com** to the sapper app which is going to be running on port 3000\n- It reroutes every call to **www.test.com** or **www.test.com/uploads** to port 1337 which is going to be the port that **Strapi** will run on\n\nThe latter is necessary if we want to enable image support since they will be located at **www.test.com/uploads/someImage.jpg** for example.\n\nOnce this is set up we need to enable this url by adding a symlink to it at **/etc/nginx/sites-enabled.**\n\nA symlink is short for **Symbolic Link** and is a way in linux to use reference to the same file in another directory. It is like having the same file in two locations at once.\n\nFor this we will simply run:\n\n```bash\nsudo ln -s /etc/nginx/sites-available/www.test.com /etc/nginx/sites-enabled/www.test.com\nsudo ln -s /etc/nginx/sites-available/www.test.com /etc/nginx/sites-enabled/test.com\n```\n\nThis enables this rerouting to be used when you access **test.com** as well as **www.test.com.**\n\nOnce this is done we can access our server as soon as it is running.\n\n## Prepare Nginx for Strapi\n\nAs discussed before we will create an admin panel at **www.admin.test.com.**\n\nWe agan start by runing:\n\n```bash\ncd /etc/nginx/sites-available\nsudo nano www.admin.test.com\n```\n\nand we will add following content:\n\n```bash\nserver {\n\tserver_name admin.text.com www.admin.test.com;\n\n\tlocation / {\n\t\tproxy_pass http://localhost:1337;\n\t\tproxy_http_version 1.1;\n\t\tproxy_set_header Upgrade $http_upgrade;\n\t\tproxy_set_header Connection 'upgrade';\n\t\tproxy_set_header Host $host;\n\t\tproxy_cache_bypass $http_upgrade;\n\t}\n}\n```\n\nAnd again save with **Ctrl-x** and the **Y.**\n\nThis also needs a symlink for wich we run:\n\n```bash\nsudo ln -s /etc/nginx/sites-available/www.admin.test.com /etc/nginx/sites-enabled/www.admin.test.com\nsudo ln -s /etc/nginx/sites-available/www.admin.test.com /etc/nginx/sites-enabled/admin.test.com\n```\n\nOnce this is done we can reload nginx via:\n\n```bash\nsudo systemctl reload nginx\n```\n\n## Deployment\n\nOur server is now ready to deploy our website to it. To get everything working we first have to make sure there is **npm** installed. For this we want node 14.x because higher versions are not stable yet and are not compatible with **Strapi**.\n\nTo install node we run:\n\n```bash\ncurl -sL https://deb.nodesource.com/setup_14.x | sudo bash -\n```\n\nThis adds the right node version to the source list of our package manager since we want to make sure that there is 14 LTS and not 16.x version of node installed.\n\nNow we install node\n\n```bash\nsudo apt -y install nodejs\n```\n\nAnd check if everything worked out by runing\n\n```bash\nnode -v\n```\n\nAfter this it is also good to install developer tools that node might need \n\n```bash\nsudo apt -y install gcc g++ make\n```\n\nOnce this is installed we also want to install **pm2** which is a process manager that helps us keep our processes running and restarts them if the server restarts.\n\n```bash\nnode install -g pm2\n```\n\nAfter this is done it's time to copy our files onto the server. For this, I advise using **Git-Bash** to copy files if you are using **Windows**. For **Linux** or **Mac,** the necessary tools should already be installed.\n\nTo copy the files we need to open a **new** terminal to make sure we're not connected to our server to our local computer where our two programs are located.\n\nThen to deploy the files to the server we simply run:\n\n```bash\nscp -r svelte_surce_folder remote_username@10.10.0.2:/remote/directory\n```\n\n**scp** stands for Secure File Copy and is a too to copy files via ssh from one computer so another.\n\nIn our case we add **-r** to make sure its also copys the contents of the folder recursively.\n\nThe second parameter is the source directory of our code. \n\nOn **Windows (Git-Bash)** that migh look like **/c/projects/svelte-blog**\n\nOne mac or linux this could be **$HOME/Projects/svelte-blog**\n\nTo get the path you can open a terminal in your project folder and type\n\n```bash\npwd\n```\n\nThe third parameter is the username of the user on the server, followed by the IP address and the path on the server that the folder should be copied. Here you can get your path again by using **pwd**.\n\n## Going Live\n\nAfter copying both the strapi backend as well as the svelte frontend to the Linux server the last thing to do is get both of them running.\n\n### Strapi\n\nSince the frontend depends on the backend it is necessary to run this first.\n\nSo the first thing to do is connect to the server again and go to the folder we just copied\n\n```bash\ncd strapi/path\nnpm install\nnpm run develop\n```\n\nOnce in the folder, we first install the dependencies and then build and start the server. Once this is done we should be able to access it via a browser by entering **admin.test.com** while test is the URL of the domain that we made above. This should enable us again to make an admin account and then create blog posts.\n\nLater we will start this via \n\n```bash\nnpm run build\nnpm run start\n```\n\nThe build is only necessary if we do changes to the structure while the start starts the built site in production mode.\n\nOnce this is running we open another terminal, connect to the Linux server again and go to the folder of the svelt project we just copied.\n\n```bash\ncd svelte/path\nnpm install\nnpm run build\nnpm run start\n```\n\nAfter this is done the frontend should be reachable via **test.com**. Again test.com has to be replaced with the URL of our domain.\n\nAfter confirming that is works the last thing necessary is to make sure they will be restarted and running in the background even if we're not paying attention to the servers. Here pm2 comes into play.\n\n## PM2\n\nTo do this we first need to start the project via pm2;\n\n### Strapi\n\nFirst stop the strapi server that we started before so the port will be free.\n\nAfter this we enter the folder for strapi again and run \n\n```bash\nnpm run build\npm2 start --name=blog_backend npm -- start\n```\n\n### Svelte Frontend\n\nAgain stop the current frontend and run\n\n```bash\nnpm run build;\npm2 start --name=blog npm -- start\n```\n\n### Saving the state\n\nOnce both processes are running through **pm2** and we can verify that they are reachable we have to save the state so **pm2** will start this state again when the machine restarts.\n\n```bash\npm2 save\n```\n\n# That's it!\n\nThis was a long ride but our blog should be up and running by now. \n\nIn this series, I only went over the main difficulties of creating a blog that way. A **Blog** or any other kind of **website** doesn't only have this but also other features that need to be implemented. This however should all be possible by using the tools we discussed and learned here in the last view posts. \n\nIf you have any questions or problems understanding a step, please feel free to contact me in the [about](https://coding-bits.net/about) form. I'm happy to help. This will also help me to update those steps to make them more understandable for future readers.","authorUrl":"/about","tags":["Strapi","Svelte","Nginx"]},{"creationDate":"2021-05-29T18:00:00.000Z","title":"Svelte, Strapi, Nginx (5)","subHeader":"How to set up Strapi and why you should","slug":"svelte-strapi-nginx-5","blogImage":"/uploads/blog_Post_Dummy_Image_c98ea26879.jpg","authorImage":"/uploads/coding_Bits_4c63b886dc.png","author":"Nils","html":"In the last post, we finished on the side of Svelte to display a blog post and enable to write code with Markdown as well as have great looking code highlighting.\n\nToday we're taking a look at **Strapi**. Why you should use it and how to set it up.\n\n# TLDR\n\nStrapi is a quick and easy way to create a backend that can easily be used by anyone creating content for a website. It is also incredibly versatile and adaptable to the needs of most static websites.\n\nI'll explain how to set it up and create a blog post object on the backend.\n\n# Why?\n\nWhen writing blog posts the easily thought of as a developer is to spend writing those posts directly in the code instead of using a backend server that servers it.\n\nIf you're a developer that knows how to write code and is experienced this is the quicker choice. There are however multiple reasons why this could be a problem:\n\n- The person that creates the website might not be the one that creates the Content for it instead it is created by:\n - A customer that hired you to create a website for him\n - A Coworker that writes the blog posts to advertise for a business\n - A copywriter that was hired to write content for your blog\n - Someone that should only have partial access to your blog but not every section of it.\n- You want multiple people to be able to write posts on your blog without being able to edit posts of other people.\n- Your blog is not just simply offering information to the user but also enables the user to send content to your backend like offering a Contact form.\n\nIf one of those is the case for you there are multiple ways to do those tasks.\n\n1. You use a CMS for frontend and backend (ex: WordPress, Joomla, Drupal\n2. You create the frontend with frameworks like react and create the backend from scratch\n3. You use a headless CMS like Strapi and only create the frontend.\n\nIn our case we're obviously choosing option 3, but let's, quickly talk about the other two options:\n\n## Using a CMS\n\nA CMS or Content Management System is a system that allows anyone to change content on a website by simple interaction on an admin panel accessible from the net.\n\nThis makes content creation quick and easy for everyone without the necessary developer expertise.\n\nThis usually involves either create your own frontend or more regularly buy themes from a seller that can be used to design how the website should look.\n\nWordPress websites are by no means bad but they usually come with one disadvantage: Every subsite needs to be loaded completely with complete disregard of the already loaded content.\nThis makes a site like WordPress, even if you enable fast loading speeds, very clunky compared to alternatives.\n\n## Use a Frontend library\n\nMany frontend libraries when developed well seems more reactive than any alternative. The user only needs to fetch the skeleton of the site once and the site uses techniques like server-side rendering with client-side rehydration to create a website that not only reacts fast to the user but also offers fluid transitions from one page to another even if the load time might be the same.\n\nGoogle calls this process [Rendering on the Web](https://developers.google.com/web/updates/2019/02/rendering-on-the-web). This is basically the same thing we do with our frontend but this comes with a problem:\n\n**We somehow need to get the data to display.**\n\nUsually, this data is taken from a database and added or modified via an admin panel that is secured via a login.\n\nCreating this backend on your own usually is just as much if not even more work than writing the frontend part. Choosing this path, however, offers full control about how the data is accessed and what kind of data can be set. \n\nBetween using a CMS to handle the backend and writing the backend completely on your own there is a middle ground. A **Headless CMS**.\n\n## Strapi\n\nA headless CMS is the backend part of a CMS. It brings an admin panel to set the data that are displayed and a REST API that offers the data that will be displayed on the website without having to redeploy the website.\n\nStrapi is a headless CMS comes with multiple advantages:\n\n- It can be self-hosted with the database of your choice\n- Its is designed to be Extensible. Every Request can be modified to do additional checks of offer additional data.\n- Its is easy to set up\n- It is open source\n- The core functionality is free to use\n\nBut let's not stay too theoretical but go into detail.\n\n# How to get started\n\nGetting started with **Strapi** is really easy you can just follow the [quickstart guide](https://strapi.io/documentation/developer-docs/latest/getting-started/quick-start.html#_1-install-strapi-and-create-a-new-project) of **Strapi** itself.\n\nI'll warp up the most important parts here.\n\nFirst, run the following command in the folder that you want your project to be created in.\n\nI but mine to **/c/Projects/** and be called **my-project**\n\n```jsx\nyarn create strapi-app my-project --quickstart\n```\n\nThis immediately sets up a project and opens up an admin panel in your default browser.\n\n![svelte_strapi_nginx_5_1.png](/uploads/svelte_strapi_nginx_5_1_9728f3c205.png)\n\nThere are ways to modify the database or other options of strapi. I'll not go too much into detail in this tutorial because that would probably be a set of posts on its own. For now, we stick with the defaults.\n\nOnce in the admin panel, we will have to set up an account that we log in with to do settings in the admin panel. If you plan on using this setup on a server directly you are probably going to set up the exact content of the database again on the server. However, there is also the possibility are never going to host this database on any server but as explained in previous chapters just run this locally and recompile your frontend to a static website locally before uploading it to a new server. More on this towards the end of the tutorial.\n\nIn any of the two cases, we are going to use this local version to set up the **Content-Types** that you are late able to push content to.\n\nAfter creating our account we are presented with the **Homepage.**\n\n![svelte_strapi_nginx_5_2.png](/uploads/svelte_strapi_nginx_5_2_2aac348e5f.png)\n\n## Creating a Blogpost\n\nLet's use this to create a Blog Post Content-type. This is as easy as it gets.\n\n1. Click on **Content-Types Builder**\n2. **Create new collection type**\n3. Enter The name of the Content-Type\n\n ![svelte_strapi_nginx_5_3.png](/uploads/svelte_strapi_nginx_5_3_d551f49747.png)\n\n4. Press **Continue**\n5. Select **Text** and enter the name Slug\nThis is going to be the unique field that allows the post to be accessed via URL later on.\n\n ![svelte_strapi_nginx_5_4.png](/uploads/svelte_strapi_nginx_5_4_9a39da19bb.png)\n\n6. To make it Unique and required we have to click on **Advanced Settings** and set Required Field and Unique Field\n\n ![svelte_strapi_nginx_5_5.png](/uploads/svelte_strapi_nginx_5_5_a4d74b19d3.png)\n\n7. After this click on **Add another field** to add our second field which is going to be a **Text** as well. This time it is called Title (No need for extra settings)\n8. Click on **Add another field** again to add a **Rich Text** for the last field called HTML which describes the blog content. (This can be HTML or even Markdown but since we called it HTML previously we are going to stick with that.\n9. Click on **Finish** and **Save** and wait for **Strapi** to reload.\n\nAfter Reload you should see a new **Content-Type** called **Blog Posts** which can now be used to write blog posts to the database.\n\n## Preparing get requests\n\nThe next thing that needs to be done is to allow any user to make a get request to **Strapi** to get the blog data.\n\nThe setting for this is tricky to find initially, but it can be done with some simple clicks nonetheless:\n\n1. First click on **Settings**\n2. Click on **Roles**\n3. Select **Public**\n4. Scroll Down to **Permission, Application** and select **count, find** and **findone** for Blog-Posts\n\n ![svelte_strapi_nginx_5_6.png](/uploads/svelte_strapi_nginx_5_6_4265aa840f.png)\n\n5. After this click on **Save**\n\nOnce this is done there are three get requests that you can make to fetch data\n\n- [http://localhost:1337/blog-posts](http://localhost:1337/blog-posts)\n- [http://localhost:1337/blog-posts/count](http://localhost:1337/blog-posts/count)\n- [http://localhost:1337/blog-posts/:id](http://localhost:1337/blog-posts/:id)\n\nThe first one fetches all the blog posts in JSON. The second one tells you the number of posts there are while the third one allows you to fetch data of a single post.\n\n## Make settings persistent\n\nAfter this is set up we can now create blog posts and request them on the server easily. This also would allow user-generated content but for our purpose, this is not necessary. \n\nAfter we are done setting up the necessary **Content-Types** that we want to display we need to make sure that the settings stay this way even when we copy our data to a server or use them on another system.\nI'm not going into detail on how to keep the data of the blog posts in sync locally and on the production server. For this, we need to select the same hosted database for both cases. \n\nIf you want more information on that you can look into the [documentation](https://strapi.gitee.io/documentation/3.0.0-alpha.x/guides/databases.html#sqlite-installation) of **Strapi**.\n\nBut aside from the data, we don't want to have to do our settings every time we move to another server.\n\nThis is not necessary however due to how **Strapi** works. \n\nAll the settings that we did while using the **Dev** backend were saved locally in code form in our project folder.\n\nTo ensure this is not lost we can simply add this folder to a **GIT** project or any other version control and work with it on any computer we want.\n\n## There is more\n\nAs you can see in the [documentation](https://strapi.gitee.io/documentation/) of **Strapi,** it is a very configurable and powerful tool to set up any CMS backend without much work. If you want to learn more about this I strongly advise you to check out the documentation.\n\n# What's next?\n\nIn the next post, we will modify our frontend to fetch the data from our strapi server. We will also talk discuss either using strapi to prebuilding our content locally into a static page or alternatively how to host strapi as well as our Sapper app on a server for server-side rendering with the help of Nginx.","authorUrl":"/about","tags":["Strapi"]},{"creationDate":"2021-03-25T20:00:00.000Z","title":"Svelte, Strapi, Nginx (4)","subHeader":"Markdown Support and code Highlighting","slug":"svelte-strapi-nginx-4","blogImage":"/uploads/blog_Post_Dummy_Image_c98ea26879.jpg","authorImage":"/uploads/coding_Bits_4c63b886dc.png","author":"Nils","html":"In the last post, I gave an example of how to use server-side fetching and rendering in **Sapper** and **Svelte** to create a blog page. Today we're going to wrap this up with another post focusing on the frontend. \n\n# TLDR\n\nIn this post, we are going to add support to write our posts using markdown and use Prism to make our code look prettier. Lastly, I will give an example of how markdown text using those two tools can look like.\n\nThis is going to be a shorter post compared to the other two but as said I wanted to wrap things up before going to the backend part.\n\n# Getting Ready\n\nThis tutorial is going to be based on the code we did in the previous post. If you are not experienced with **Svelte** and **Sapper** I advise you to look at this one first.\n\n# Showdown\n\n## What is Markdown\n\nThe first thing we are talking about is enabling markdown support for our blog content. In case you don't know what markdown is:\n\n\"Markdown is a lightweight markup language for creating formatted text using a plain-text editor.\" (source: [Wikipedia](https://www.wikiwand.com/en/Markdown)) \n\nIn other words, it's an easy way to format text that can not only be easily made to look good in the browser but also be easily understood by every plain texteditor.\n\nIn case you want to know more about how markdown formatting looks like I can advise you on this **[Cheatsheet](https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet)** by Adam Pritchard.\n\n## Installing the prerequisites\n\nFor this, we are not writing the code completely from scratch. That would be a waste of time, given that there are many good open-source packages to freely use.\n\nThe package we're going to use is **[Showdown](http://showdownjs.com/)** which is a free open source javascript package that does the job well.\n\nTo install it we have to go to open a terminal like **git bash** or **bash** and go to the directory that our **Svelte** project is in. There we run the following command:\n\n```bash\nnpm install showdown\n```\n\nAfter this part is done its time to go to our blog page that renders the Content\n\nThis should look like this:\n\n```html\n\n\n\n\n\n\n\n {post.title}\n\n\n

{post.title}

{post.subHeader}

\n\n

\n {@html post.html}\n

\n```\n\nHere the first thing we will mostly do changes in the script tag but also a small edit in the content div: \n\n```html\n\n\n```\n\nAbove we can see the changes in the script tag. We import the showdown converter from npm, as well as the before update hook that svelte offers.\n\nThis hook is called whenever the props (in our case the post variable) changes their value. We then update the content variable before the values are set to display the right data. \n\nIn addition to the **beforeUpdate** hook, we have to add the code outside, because **beforeUpdate** is callback is not called on the initial load.\n\nNow the content variable is a html string that was converted from showdown. This needs to be loaded in the html below instead of the original html data of the post:\n\n```html\n

\n {@html post.html}\n

\n```\n\nThis finishes the markdown support.\n\nThe next step is to make the code highlighting look better.\n\n# Prismjs\n\nFor this I used Prismjs. In here two things have to be done. \n\n1. Get the CSS to set up the styling\n2. Get the javascript to add the right CSS classes to a code block that should be highlighted\n\n## Css\n\nFor the styling I advise, to go to The [Prism.js](https://prismjs.com/download.html#themes=prism-twilight&languages=markup+css+clike+javascript) page to generate a minified css element.\n\nJust pick your theme, all the programming languages you want to be enabled, and download the CSS.\n\n## Javascript\n\nHere we can also use the javascript from Prism.js directly, import that locally, and use the code this way.\n\nI decided to instead use the npm package since the imports are quicker and its easier to update.\n\nFirst, you should run the following command in the root folder of your project.\n\n```bash\nnpm install prismjs\n```\n\nAfter this is installed we met all our perquisites to put those two together.\n\n## Putting things together\n\nI put my CSS into src/css so the import call should be something like **import \"../../css/prism.css\"**\n\nIn addition we want to import **prismjs** and **prismjs/plugins/normalize-whitespace/prism-normalize-whitespace.min.js** to remove whitespaces and tabs in our code when not necessary. \nRemoving this makes the markdown easier and faster to write.\n\nWe also need two new svelte hooks: **afterUpdate** and **onMount**.\n\nThe **script** tag should then look something like this.\n\n```html\n\n```\n\nFirst, on the mount, we want to install the **NormalizeWhitespace** Plugin to make sure that our code is trimmed right. Then when this is set up it is as simple as calling **Prism.highlightAll()** to tell prisms to highlight all the HTML pre blocks that are there\n\n# Example Markdown\n\nOnce this is done all we need to do is write our markdown to make our blogpost look good. In here I provide some example that combines the markdown with the code highlighting\n\n

\n  \n#H1 Tag\nThe above text is transformed into h1 while this is not\n\n```javascript\nlet a = \"This is javascript code that is going to be highlighted by prismjs\nconsole.log(a)\n```\n\n[logo]: https://github.com/adam-p/markdown-here/raw/master/src/common/images/icon48.png \"Logo Title Text 2\"\nThe image is an image that is going to be centered with HTML directly in markdown\n  \n

\n\nThe above code shows general markdown capabilities and how a blog post could be written.\n\n# What's next?\n\nIn the [next post](/blog/svelte-strapi-nginx-5), it is going to be time to build our backend. I will talk about Strapi and how it can be used to create a fast backend server that enables REST API calls as well as the use of Graphql together with a lot of possible database setups. Without much coding needed although possible for easy customization.","authorUrl":"/about","tags":["Svelte","Sapper"]},{"creationDate":"2021-03-16T20:00:00.000Z","title":"Svelte, Strapi, Nginx (3)","subHeader":"Fetching Data from the backend and prerendering a blog page.","slug":"svelte-strapi-nginx-3","blogImage":"/uploads/blog_Post_Dummy_Image_c98ea26879.jpg","authorImage":"/uploads/coding_Bits_4c63b886dc.png","author":"Nils","html":"[Last post](/blog/svelte-strapi-nginx-2) we talked about how to use sapper to create a website with Svelte. We discussed the general Routing and the way a svelte pate is set up. We also made a quick turn to talk about the difference in hosting your website and how sapper supports both. Now it's time to get into more detail and offer an example of how a Blog page could be looking.\n\n# TLDR\n\nIn this post, we will see how a website showing a blog post could be created in sapper and svelte and how we can fetch data from a server. After the website is built we talk about how to make it ready for deployment to a v-server or a static hoster depending on choice and preference. \n\n# Getting Ready\n\nIn the last example I explained the prerequisites of getting started with sapper. I also explained how we can create our first project with some dummy data. In here I will use this data, modify it and explain what it does. If you want to follow along with this tutorial you should create your own project, if not done so already. \n\nIf you already have the prerequisites installed and just forgot the command its:\n\n```bash\nnpx degit \"sveltejs/sapper-template#rollup\" testProject\n```\n\nafter our project is created we have to first run **npm install** in the new test project folder and afterward \n\n```bash\nnpm run dev\n```\n\nthen we can head over to **[localhost:3000](http://localhost:3000)** to use the dummy version of a blog created by sapper.\n\nThe current version of the blog post can then be seen under **[localhost:3000/blog/how-to-use-sapper](http://localhost:3000/blog/how-to-use-sapper)** . After this, we are done and ready to start coding.\n\n# _posts.js (aka setting up dummy data)\n\nWe will keep all the defaults in regards to the header and the index blog page for now and focus on the blog post in this tutorial. In fact, we are going to use files that are already set to offer the data.\n\nThe first file we will look at is at **testProject/src/routes/blog/_posts.js**. \n\n```javascript\n// Ordinarily, you'd generate this data from markdown files in your\n// repo, or fetch them from a database of some kind. But in order to\n// avoid unnecessary dependencies in the starter template, and in the\n// service of obviousness, we're just going to leave it here.\n\n// This file is called `_posts.js` rather than `posts.js`, because\n// we don't want to create an `/blog/posts` route — the leading\n// underscore tells Sapper not to do that.\n\nconst posts = [\n\t{\n\t\ttitle: 'What is Sapper?',\n\t\tslug: 'what-is-sapper',\n\t\thtml: `\n\t\t\t

First, you have to know what Svelte is. Svelte is a UI framework with a bold new idea: rather than providing a library that you write code with (like React or Vue, for example), it's a compiler that turns your components into highly optimized vanilla JavaScript. If you haven't already read the introductory blog post, you should!

\n\n\t\t\t

Sapper is a Next.js-style framework (more on that here) built around Svelte. It makes it embarrassingly easy to create extremely high performance web apps. Out of the box, you get:

\n\n\t\t\t

Code-splitting, dynamic imports and hot module replacement, powered by webpack
Server-side rendering (SSR) with client-side hydration
Service worker for offline support, and all the PWA bells and whistles
The nicest development experience you've ever had, or your money back

\n\n\t\t\t

It's implemented as Express middleware. Everything is set up and waiting for you to get started, but you keep complete control over the server, service worker, webpack config and everything else, so it's as flexible as you need it to be.

\n\t\t`\n\t},\n\n\t{\n\t\ttitle: 'How to use Sapper',\n\t\tslug: 'how-to-use-sapper',\n\t\thtml: `\n\t\t\t

Step one

\n\t\t\t

Create a new project, using degit:

\n\n\t\t\t

npx degit \"sveltejs/sapper-template#rollup\" my-app\n\t\t\tcd my-app\n\t\t\tnpm install # or yarn!\n\t\t\tnpm run dev\n\t\t\t

\n\n\t\t\t

Step two

\n\t\t\t

Go to localhost:3000. Open my-app in your editor. Edit the files in the src/routes directory or add new ones.

\n\n\t\t\t

Step three

\n\t\t\t

...

\n\n\t\t\t

Step four

\n\t\t\t

Resist overdone joke formats.

\n\t\t`\n\t},\n\n\t{\n\t\ttitle: 'Why the name?',\n\t\tslug: 'why-the-name',\n\t\thtml: `\n\t\t\t

In war, the soldiers who build bridges, repair roads, clear minefields and conduct demolitions — all under combat conditions — are known as sappers.

\n\n\t\t\t

For web developers, the stakes are generally lower than those for combat engineers. But we face our own hostile environment: underpowered devices, poor network connections, and the complexity inherent in front-end engineering. Sapper, which is short for Svelte app maker, is your courageous and dutiful ally.

\n\t\t`\n\t},\n\n\t{\n\t\ttitle: 'How is Sapper different from Next.js?',\n\t\tslug: 'how-is-sapper-different-from-next',\n\t\thtml: `\n\t\t\t

Next.js is a React framework from Vercel, and is the inspiration for Sapper. There are a few notable differences, however:

\n\n\t\t\t

It's powered by Svelte instead of React, so it's faster and your apps are smaller
Instead of route masking, we encode route parameters in filenames. For example, the page you're looking at right now is src/routes/blog/[slug].svelte
As well as pages (Svelte components, which render on server or client), you can create server routes in your routes directory. These are just .js files that export functions corresponding to HTTP methods, and receive Express request and response objects as arguments. This makes it very easy to, for example, add a JSON API such as the one powering this very page
Links are just <a> elements, rather than framework-specific <Link> components. That means, for example, that this link right here, despite being inside a blob of HTML, works with the router as you'd expect.

\n\t\t`\n\t},\n\n\t{\n\t\ttitle: 'How can I get involved?',\n\t\tslug: 'how-can-i-get-involved',\n\t\thtml: `\n\t\t\t

We're so glad you asked! Come on over to the Svelte and Sapper repos, and join us in the Discord chatroom. Everyone is welcome, especially you!

\n\t\t`\n\t}\n];\n\nposts.forEach(post => {\n\tpost.html = post.html.replace(/^\\t{3}/gm, '');\n});\n\nexport default posts;\n```\n\nLater when we learn how to add Strapi to this we will get our initial data differently but for now this will be the file that we get our data from.\n\nFor our example, we won't just stop with a title and some HTML but also add a subHeader, and a thumbnail picture to it. Especially the image is going to be important in a later post when we will talk about Nginx and strapi. For now, we can just keep it here.\n\nOne Object in the array might then look like this:\n\n```javascript\n\t{\n\t\ttitle: 'How can I get involved?',\n\t\tsubHeader: 'Detailed information how to get involved',\n\t\tslug: 'how-can-i-get-involved',\n\t\thtml: `\n\t\t\t

We're so glad you asked! Come on over to the Svelte and Sapper repos, and join us in the Discord chatroom. Everyone is welcome, especially you!

\n\t\t`,\n\t\tpictureSrc: 'https://images.pexels.com/photos/169573/pexels-photo-169573.jpeg?auto=compress&cs=tinysrgb&dpr=3&h=750&w=1260'\n\t}\n```\n\nThe picture is from [server-sidePexels](https://www.pexels.com) which is alongside U[nsplash](https://unsplash.com/) a great source for free commercially usable images. \n\nLater when we talk about Strapi the images are going to be hosted alongside all the other data on our own backend but since this is going to be a later topic we will use external images for now.\n\n# [slug].json.js\n\nNow that our dummy data is ready its time to do the server side fetching of data. In the last post I talked about dynamic pages vs static pages. To enable the advantages of a dynamic page the fetching to the data is done on the server. Since on our case the data won't change very often this enables things like caching of the data because the prerendered html is going to be send to the client. This also allows to only send the necessary data to the client or do the database call only once data are changed. \n\nUsually, those database calls are what make the scalability of websites a challenge. It's easy to just run another instance of the frontend but it's a challenge to duplicate a database. As stated before sapper even allows to statically pretender a website to host the frontend on a static hoster which is usually cheaper. For this, the fetching must be done separately to the direct frontend.\n\nThe file **testProject/src/routes/blog/[slug].json.js** allowes this. The naming is intentionally set like this. It tells svelte that the name itself can be a wildcard. it can be replaced by any value which is then used to do a lookup for the data of the post.\n\nWhen a user does a fetch call to **blog/${slug}.json** this file looks up if there are data and returns them, or returns an error message.\n\nThe initial version looks like this:\n\n```javascript\nimport posts from './_posts.js';\n\nconst lookup = new Map();\nposts.forEach(post => {\n\tlookup.set(post.slug, JSON.stringify(post));\n});\n\nexport function get(req, res, next) {\n\t// the `slug` parameter is available because\n\t// this file is called [slug].json.js\n\tconst { slug } = req.params;\n\n\tif (lookup.has(slug)) {\n\t\tres.writeHead(200, {\n\t\t\t'Content-Type': 'application/json'\n\t\t});\n\n\t\tres.end(lookup.get(slug));\n\t} else {\n\t\tres.writeHead(404, {\n\t\t\t'Content-Type': 'application/json'\n\t\t});\n\n\t\tres.end(JSON.stringify({\n\t\t\tmessage: `Not found`\n\t\t}));\n\t}\n}\n```\n\nThe first part of the function is immediately called when the sapper backend is started. it loads the posts defined in the object set above and creates a Map for easily looking up posts later when the data are loaded. For now, we will still get our data from the _posts.js file, but we will treat this as if the data come from a server instead of just a file, which forces us to use asynchronous code instead of synchronous code currently used.\n\nThe Asynchronous Request looks something like this\n\n```javascript\nimport posts from './_\nposts.js';\n\nlet fetchedLast = 0; // MODIFIED To ensure refetcing of the data every 5 minutes\nconst lookup = new Map();\n\n//MODIFIED Update the new data instead of just doing it once\nfunction updateLookupData(posts){\n\tposts.forEach(post => {\n\t\tlookup.set(post.slug, JSON.stringify(post));\n\t});\n}\n\n//Fetch the data\nasync function fetchData(){\n\tlet result = new Promise((resolve, reject) => {\n\t\tsetTimeout(() => {\n\t\t\tresolve(posts);\n\t\t}, 3000)\n\t});\n\t\n\tupdateLookupData( await result)\n\treturn lookup;\n}\n\n//MODIFIED Either refetch the data or use saved data\nasync function getData(){\n\tif ( ( Date.now() - fetchedLast ) >= 1000*60*5 ){\n\t\tlet result = await fetchData();\n\t\tfetchedLast = Date.now();\n\t\treturn result;\n\t}\n\treturn lookup;\n}\n\n//MODIFIED to be async\nexport async function get(req, res, next) {\n\t// the `slug` parameter is available because\n\t// this file is called [slug].json.js\n\tconst { slug } = req.params;\n\n\t//MODIFIED Get up to date data\n\tlet lookup = await getData();\n\n\tif (lookup.has(slug)) {\n\t\tres.writeHead(200, {\n\t\t\t'Content-Type': 'application/json'\n\t\t});\n\n\t\tres.end(lookup.get(slug));\n\t} else {\n\t\tres.writeHead(404, {\n\t\t\t'Content-Type': 'application/json'\n\t\t});\n\n\t\tres.end(JSON.stringify({\n\t\t\tmessage: `Not found`\n\t\t}));\n\t}\n}\n```\n\nI added comments with the word **MODIFIED** to show the contents that have been updated.\n\nThe first thing we did was move the setting of the lookup data in its own function **updateLookupData.** Once the data are fetched this updates the table to offer the new values.\n\nNext, we created a function **fetch data** that fetches the data from a server. In our case, this is only simulated since we get the data from the client we just run a setTimeout Function which returns the result after 3 seconds. This function later has to be updated to fetch the actual data from the backend (in our case from **Strapi**). We will do this in a later post.\n\nLastly, the function **getData** returns either fetches the data again from the server if the data have not been fetched for at least 5 minutes or just returns the current table if it has been fetched. Instead of relying on the Map() from a variable, we take the map via this function in the get request to ensure that the data are always up to date. \n\nThe **get** function has to be asynchronous to ensure that we are now waiting for the fetch request before we give out the result.\n\n# [slug].svelte\n\nThe last File that we need for our blog post is the **[slug].svelte** file. This is the actual frontend that is going to display what the user sees. This file itself is never going to be seen by the User. It is merely to be compiled into actual HTML, CSS, and javascript by the svelte compiler.\n\nBefore we go to the content let's again talk about the name of this file. Like in the case above the name **[slug]** part of the name is merely used to stand as a wildcard. When loading the website like **http://localhost:3000/blog/slug** the slug part is merely to tell the compiler what blog data should be displayed.\n\nAgain for those who won't code along the file looks like this:\n\n```html\n\n\n\n\n\n\n\n\t{post.title}\n\n\n

{post.title}

\n\n

\n\t{@html post.html}\n

\n```\n\nIn this file there are several things too look at.\n\nFor once there is not one but two script tags. One which has the **context=\"module\"**. This tag is different from the typical script instance in two ways.\n\n1. The script called in module context runs only once and acts as a static variable, existing for all svelte components. A variable declared here can be accessed by every other instance of this component. In [this tutorial](https://svelte.dev/tutorial/sharing-code), the creators of svelte offer a good example of how this can be useful.\n2. Every variable and function exported in this tag can be accessed via import by every module. This allows the preload function to be accessible for sapper when the file is loaded.\n\nThe preload function is the function that **Sapper** uses to fetch data on the server side even before that Component is rendered to the client. It fetches the blog/slug.json and sets those data in the post property once the data are fetched.\n\nThe second script tag is simple there to offer a property that can be accessed set by the parent of this component or via the preload function.\n\nThe **style** tag as I talked about in the previous tutorial is pretty self-explanatory. As discussed before all the styles here are unique to this component so as a developer we won't need to worry that other developers might overwrite our CSS in other stylesheets.\n\nHere we are going to add some CSS to ensure the right scaling of our header image that we specified in the dummy post data.\n\n```css\n\n\t.headerImage{\n\t\tmax-width: 100%;\n\t}\n\n```\n\nNext we have the **** part which is a svelte unique component that allows doing changes on the head of the HTML as long as the component is loaded into the dom.\n\nWe use this to change the title of the tab bar when our post is open.\n\nLastly, we have the HTML part that describes our post. Here we will add two tags:\n\n```html\n

\n```\n\nabove the **h1** and\n\n```html\n

{post.subHeader}

\n```\n\nbelow it to display a image for our post and the subheader text.\n\nOne thing to mention in here is the last div of the component\n\n```html\n

\n\t{@html post.html}\n

\n```\n\nThis div is special since the text that is set here is not evaluated as a string but as HTML. This is achieved by adding **@html** in front of the variable.\n\nThe final result looks like this:\n\n```html\n\n\n\n\n\n\n\n\t{post.title}\n\n\n

{post.title}

{post.subHeader}

\n\n

\n\t{@html post.html}\n

\n```\n\nThis completes our new blogpost. It can be accessed just like the last one **[localhost:3000/blog/how-to-use-sapper](http://localhost:3000/blog/how-to-use-sapper) .**\n\nThis of course won't win any styling awards but it should generally show how creating dynamic content in sapper works.\n\n# Building a dynamic or static site\n\nNow that you know how to Create and prefetch data for a blog page you can apply this knowledge to other areas of your site. Like the list of all posts or the home page. \n\nAfter you are comfortable with how your blog looks it's time to either make a dynamic or a static page. In the previous post, you can see the advantages of a static site or a dynamic site. I will not go further into detail on which one you should choose.\n\nFor a dynamic site all you will need to do ist run:\n\n```bash\nnpm run build\nnpm run start\n```\n\nThis will generate the dynamic site for you and start it. Usually, this should be done from a server like the virtual server [Digital Ocean](https://www.digitalocean.com/) offers. Usually, this is going to be a Linux server. If you prefer a static hoster then you will need to run another command\n\n```bash\nnpm run export\n```\n\nThis starts the server to enable prefetching of the data, seeks through all the links that your site refers to, and generates a static site for each link it can find.\n\nThis then can be uploaded directly to a static hoster.\n\n# What's next?\n\nIn the next post, we will look at the blog page again to enable support for code highlighting and markdown. Markdown is a great text syntax that allows writing good posts quickly and make them look good. It also allows using HTML whenever there needs to be a better way of displaying parts of the text. If this is not of your interests and you are not planning to create a blog but rather another website then you can skip that post and read the one after when I talk about **Strapi**. A quick and easy way to create a server for setting content.","authorUrl":"/about","tags":["Svelte","Sapper"]},{"creationDate":"2021-03-06T19:00:00.000Z","title":"Svelte, Strapi, Nginx (2)","subHeader":"How to use Svelte? What the heck is sapper? And the general Routing.","slug":"svelte-strapi-nginx-2","blogImage":"/uploads/blog_Post_Dummy_Image_c98ea26879.jpg","authorImage":"/uploads/coding_Bits_4c63b886dc.png","author":"Nils","html":"# TLDR\n\nIn this post, I will first talk about how to get started with Svelt and Sapper and offer the toolbox needed to create your first web app. I will also explain another advantage of using **Sapper** by comparing static pages and dynamic pages and showing how sapper can combine the advantages of both of them. If this all seems to lack examples to you, don't worry. In the next post, I will show some of the things explained here in detail by the example of a blog post page.\n\n# Getting started\n\n## Prerequisites\n\n### node & npm\n\nIf you are working under windows I would advise you to install [git for windows](https://gitforwindows.org/) and the git bash that comes with it. Most of the named commands can be run in either Powershell (or git bash) under Windows or the equivalent terminal in Linux or mac.\n\nThe next thing you need is nodejs installed (as most developers probably already will have if this isn't your first rodeo) if not you can download it [here](https://nodejs.org).\n\n### yarn\n\nCurrently, it is not advised by the [svelte team](https://twitter.com/sveltejs/status/1221540640615489540) to use yarn because yarn changes its way to handle require which creates a problem with the unconventional decision of sapper to use a ```node_modules``` folder in the src directory as well as the root directory.\n\n## Setting Up the Project\n\nNow that everything necessary is set up correctly it's time to get started.\n\nThe first thing we need to do is create a project directory. This is done by first opening the terminal and going to the folder that we want our project to be in. In my case, I created my Project in /c/Projects. To go there in git bash we need to call\n\n```bash\ncd /c/Projects\n```\n\nfrom there you call \n\n```bash\nnpx degit \"sveltejs/sapper-template#rollup\" my-app\n```\n\nwith my-app being the name chosen for your website folder. \n\nAfter this its time to install the necessary dependencies and start the initial dummy version of the project\n\n```bash\ncd my-app\nnpm\nnpm run dev\n```\n\nafter this the terminal should state something like:\n\n```bash\n> Listening on http://localhost:3000\n```\n\nalong with other data. This is the URL you have to enter in the browser to see how the website looks. While npm run dev is running we can open the folder we just created with an editor of our choice.\nI recommend using [VS Code](https://code.visualstudio.com/) and edit the files. Doing changes on the files will immediately update the website displayed on the browser. \n\nFor example, we can open the file ```/src/routes/index.svelte``` and change the \n\n```html\n

Great success!

\n```\n\nto \n\n```html\n

Hello Word

\n```\n\nThis updates the index page (=the first page showed when entering the URL) to display \"Hello World\".\n\nIn the next part, we will stay in this file to go into more detail how a svelte file looks like. Afterward, I will explain the general structure of the project to give a better understanding of what all the created files do.\n\n# Understanding File Structure:\n\nThe goal with Svelte as with the other Frameworks is to encourage the use of Components. In general, a Svelte file has 3 Important Parts:\n\n1. The script tag\n2. The Style tag\n3. The HTML\n\n```html\n\n\n\n\n\n\tSapper project template\n\n\n

Great success!

\n\n

Try editing this file (src/routes/index.svelte) to test live reloading.

\n```\n\nThe **script tag** is run the second the Component is created to enable dynamic behavior. This however does not mean that the javascript that is run there is run in the context of a web browser. It is run by the compiler to compile the svelte file into an HTML equivalent. It is not guaranteed that typical browser variables like **windows** are there at compile time. The use of variables like **window** is generally possible when using **lifecycle** hooks like **onMount** but should be avoided as there are generally better alternatives that produce better code structures. \n\nThe **style tag** is mostly like the style tag an HTML file would use. The style used here however only applies to the HTML in this component. The same class in another component would not be changed by it. This enables to be less cautious about class names and to only focus on one component at a time without worrying what side effects this might have on the other Components.\n\nLast but not least the **HTML** part of the file can, in general, be seen as simple HTML. It is however also possible to access variables from the script file directly in there. In the example above, the script tag imports a file called success kid which is directly referenced in the src attribute of the tag further down in the code.\n\nTo understand Svelte more and all the different nuances I advise you to look into the interactive [tutorial](https://svelte.dev/tutorial) offered by the creators of Svelte. \n\n# Understanding the project structure\n\nNow that we talked about the most important file type we should take a general look into the project folder to understand what our blog will be made of.\n\n![Untitled.png](/uploads/Untitled_e03c632f6e.png)\n\nIn here you can for once see the **__sapper__** folder. This folder can be ignored for now it mostly just contains the generated files after the browser is done compiling.\n\nThe ```node_modules``` folder is as most of you will probably know also automatically generated by npm. It contains all the dependencies of the website. There exists another ```node_modules``` folder in the **src** folder which is used by sapper to allow easier importing of the lifecycle method and other components.\n\nThe **scripts** folder exists to offer useful scripts. Here could be a deploy script to your server or in the case of sapper a script to enable typescript. For this tutorial, we will keep our project to plain javascript, so this folder can also be ignored.\n\nThe next folder is the most important folder for us. The **src** folder.\n\n### src\n\n![Untitled 1.png](/uploads/Untitled_1_5fe4eeee6f.png)\n\nThis is the folder where our code will mostly be written.\n\nHere we have the **components** folder which holds all the components that we use to build our web app. The first component that is initialized is the header bar. The header bar is the same on many pages as it enables navigation through the website. So it makes sense to create a component from it.\n\nThe next folder that is important is the **routes** folder. This folder describes what should be opened of the path ```localhost:3000/``` , the path ```localhost:3000/about``` or the path ```localhost:3000/blog```. \n\nThe first part is the URL which just tells the browser where to request the files. The part with the / tells the browser the path of the files requested.\n\nThe routing is done in the following order:\n\n1. Look for the index.js in the given path. \n2. If it does not exist look if the last part of the path has a file that responds to the name.\nex.: about.json\n3. If neither exists look for a [slug].svelte\n4. If not open the _error.svelte\n\nAside from this routing, you can see a **_layout.svelte** file in the route directory. This file functions as the container of the above-loaded files. \n\nIt has a `````` tag which describes where the above requested svelte component should be put.\n\nThis is for example used to always render the Navigation bar on every website without setting it in every component.\n\nThe rest of the files in the src folder can be ignored for now. They are used by sapper to enable start the frontend client and server as well as describe where the code in the HTML should be placed.\n\n### static\n\n![Untitled 2.png](/uploads/Untitled_2_876370d8fd.png)\n\nThe last folder is the **static** folder. It holds static files that need to be accessed by the HTML. Those will be placed at the root of the website. \n\nFor example ```http://localhost:3000/favicon.png``` loads the favicon.png.\n\nThis can be used to set up static assets that won't dynamically change in the future.\n\nThere is also a global.css file that enables to use CSS globally.\n\n### Rest\n\nThe rest of the files are useful too but going into too much detail would make this post even longer than it is already going to be. I encourage you to take a look at the [sapper documentation](https://sapper.svelte.dev/docs/) to read more about the file structure.\n\n# Static vs Dynamic pages\n\nThe tools above should be enough to enable you to start writing your own web app using svelte and sapper. At least the basics. In the next post, I'll talk a little more about examples of displaying data. For now, there is another thing I'll have to talk about to round up the advantages of using Sapper.\n\nFor this, we have to understand the difference between a Static and a Dynamic Website.\n\n## Static Website\n\nA Static website is a website that does not do any calculations on the server-side. It simply hosts the files that are going to be shipped to the user. Afterward, the site usually runs javascript code in the browser to enable fetch dynamic content.\n\nLet's say the user wants to see the route ```localhost:3000/blog?post=post123```. But the post has to be fetched from another server.\n\nThis means the user first asks the Server for an HTML file which is then interpreted by the server to load the information of the Post from another server (given that the post is not hardcoded).\nHardcoding Dynamic content like a post is usually not a good idea since we might want to enable editors that are not experienced in HTML to write posts.\n\nThis approach has several **advantages** but also **disadvantages**\n\n### Advantages\n\n- The server only needs to send precomputed HTML which means that the server needs way less logic and computation power.\n- There is a lot of cheap and easy hosting options for static websites\n- Improved security against attacks on the site hoster (if the content server is not vulnerable)\n\n### Disadvantages\n\n- Overall slower \"contentful paint\" because there needs to be an extra request to another server to get the dynamic data to display.\n- The client has to have access to the database or another server delivering the content which makes this possibly be attacked\n- Without a database or a server serving the content has to be added by the programmer of the website. (Need of technical knowledge.\n\n## Dynamic Website\n\nA dynamic website is a website where the server is not just serving files but also runs logic before the content is served. This can be fetching content from a database, making sure the user is allowed to access the data via authentification header, or prerendering and optimizing data before the user even sees the page for the first time. This has advantages or disadvantages as well.\n\n### Advantages\n\n- Logic is done serverside which can make caching of similar requests easier (if they don't change too quickly)\n- Content can be saved on a per-user basis without the user having access to a database.\n- Faster load times\n\n### Disadvantages\n\n- Harder load on the server because every non-cached request has to make calculations.\n- Static hoster are usually more expensive\n\n## Fetching Data on the Server\n\nThis project was initially thought out to be used by a non-techy person (you can read the reasons behind it in the first post). \n\nCreating a page that needed to be updated by the developer if new content was to be added was out of the question. This either meant that I could create a static page that lets the user load content from a server every time or a dynamic page that loads the data on the backend site which made caching easier.\n\nIn both cases, this needed a backend or serverless architecture to offer the website which means higher costs overall.\n\n### Or not...\n\nHere the strength of **Svelte** and **Sapper** comes into play. \n\nSapper not only allows to easily offer a dynamic website that prerenders the website and when done right only requests data from the server when they change.\n\nIt goes a step further and can return a static page based on the contents fetched from a server.\n\nThis means you can offer a small lightweight Linux server for the client that listens to changes on the backend and then on changes rerenders the website to a static site to post it directly to a static hoster.\n\nIf the user is just a little tech-savvy you could even enable him to run this script on his home computer. This means the user has to:\n\n- Run the CMS Admin panel locally\n- Do the changes in the CMS\n- Wait for the CMS to rerender the static page and redeploy it directly to the static hoster.\n\nThis easily takes away the need for an expensive Linux server, while keeping all the advantages of a CMS. \n\nFor a blog, this way should be completely sufficient.\n\n# What's next?\n\nNext up I'll take an example blog post File in sapper to explain the above-learned features in more detail. I'll explain how to use **Sapper** to fetch the content of a blog page on the server-side and how to generate a dynamic website and render it as a static website that can be deployed to a static hosting provider.","authorUrl":"/about","tags":["Svelte","Sapper"]},{"creationDate":"2020-02-21T14:00:00.000Z","title":"Svelte, Strapi, Nginx (1)","subHeader":"How to create a modern website using Svelte, Strapi and Nginx. In other words: How I Created this coding blog - The Who's, What's and Why's.","slug":"svelte-strapi-nginx-1","blogImage":"/uploads/blog_Post_Dummy_Image_c98ea26879.jpg","authorImage":"/uploads/coding_Bits_4c63b886dc.png","author":"Nils","html":"# TLDR\n\nThe whats, hows, and whys of this tech stack.\n\nBefore we go into coding it becomes more and more important to take a step back and think about why you are using the Stack that you are using. In a sea of hundreds of frontend and backend frameworks, this is not an easy question.\n\nIf this bores you or you can't wait for the sweet action I encourage you to just skip this and go to the [next part](/blog/svelte-strapi-nginx-2).\n\n# Who?\n\nI am a young Full Stack developer who works in a startup that creates WebAR and WebVR solutions for B2B. I was always interested in learning frameworks and skills surrounding all kinds of development. Usually, I enjoy the ones where you can see and show your results to the whole world. Aka Web development and App development. I created an Android / IOS App during college and now create 3D experiences for other businesses. \n\n# Why?\n\nSome months back I gave myself the challenge to see how long It would take me to create a functioning website that would be easy for a martial arts school I trained at. I wanted the website to be easy to use and make changes for the Trainer who had zero experience with anything electronic. But I, as an engineer at heart, also wanted it to have all the bells and whistles an up-to-date website offers. How else would this be a challenge, right?\n\nThe first version of the Site was created for free with the thought of possibly selling it to the school. However, the school ended up closing down due to corona so the work was never to be displayed.\n\nI couldn't let those fresh learned skills and Ideas come to waste so I decided to create the Blog I always thought about making to reality and use this tack Stack to create it.\n\n# What?\n\nWhat was so special about the tech stack that I used? Special enough to create a whole blog around it?\n\n## The Frontend\n\nAssuming you didn't sleep while reading the header you already know what I used of the Frontend.\n\nIn a sea of millions of frontend frameworks which to choose and why is a question that is hard to answer. So let's compare the frameworks and see how they would apply to this project. \n\nI will NOT go into detail in this thread because there are tons of other people comparing these frameworks in detail. I will try however to get the general gist that seems to be talked about.\n\n![FrameworkVanila.jpeg](/uploads/Framework_Vanila_98efee6ef4.jpeg)\n\n### VanillaJS\nVanilaJs is good to know. In fact, without the basics, you should not even start thinking about using any frameworks. A developer not understanding the basics will lead to overcomplicating the simplest tasks just because they won't know a better or intended way.\n\nHowever, once you learn to use any of the soon mentioned frameworks and their benefits you won't want to ever develop VanilaJs in a project.\n\nThose Benefits include:\n\n- Hot module replacement\n- Component-Based Development\n- Client-Side Rendering\n- Server-Side Rendering ( With Rehydration)\n- Better Performance\n\nAll these benefits can be created with Vanilla JS but not without significant overhead and with making the code more Complicated to understand or manage.\n\n### Angular (Did Anybody say complicated?)\n\nThere is barely a talk about web frameworks without the word Angular being thrown around. The by now over 10-year-old Web Framework created by Google engineers is still used by many web developers. It is described as stable, mature and offers an incredibly high number of official tools for whatever you want to create with it. It is however also described as hard to learn.\n\n![js-learning-curves.jpeg](/uploads/js_learning_curves_6cbd2463fc.jpeg)\n\nAngular as the first big web framework was created to handle big amount of developers working on the same project without the project looking like a huge mess after some weeks.\n\nA framework like Angular is incredibly useful if you are working in a big hierarchical company where you might not even know or be able to talk to the other guy in person that is working on another feature in the same project as you do.\n\nThe disadvantage is that Angular needs a lot of structure and Initial setup to even get the simplest of things done. Not so ideal for a project that I'm working on alone on a Weekend.\n\n### React \nFor a long time, React was the new kid on the blog. Created in the small tiny company called Facebook, react was basically a big Competitor to Google's Angular.\n\n![xml-while-html.jpg](/uploads/xml_while_html_b80f24f1a6.jpg)\n\nIn contrast to Angular React showed itself to be just as Fast, but way easier to start and get to development. If you wanted the extra features of Angular you can just use additional packages created by the community.\n\nAnd here we reach Reacts biggest Strength: Its Community. For almost all tasks Necessary there is already a community build Component ready to just \"npm install\" and use. \n\nAnother good side to mention is that you can use a big junk of what you learned in React to create fancy cross-platform Apps in React Native. (Learn once, build anywhere).\n\nThe reliance on the huge community of React also comes with some disadvantages. Whenever react brings out some new breaking changes, which they kept doing for years with a rapid pace of development (they are slowing down in this matter for some time) there is a chance that a big junk of your web app breaks because the packages used are not able to keep up.\n\nApart from constant breaking mixing different components that were created by different people can make the code more complicated than it has to be, and makes its setup time, although not as slow as in Angular still rather slow for a weekend project.\n\nAll in all, I would still say that react is a good framework even for smaller projects. It's just that there are new concepts popping up that are leaner, for smaller projects.\n\n### VueJS\n\nIn today's web development world, a website has to be build reactive. When a user clicks a button he immediately wants to see something happening.\n\nThe problem is that usually not the whole page needs to be reactive but only certain parts of it. For example, the container displaying the fetched data.\n\nAlso, there are still a lot of websites out there that are built without a lot of reactivity build in.\n\n![vue-meme.jpg](/uploads/vue_meme_4658acf475.jpg)\n\nThis is where Vuejs (also created by google) comes in.\n\nVueJS is build to be easily put in place in an existing HTML page by adding a script and calling the constructor function. After this VueJS (as the View part in the MVC design pattern) reacts to changes in the data to immediately and fastly react to changes and display them on the page.\n\nThis feature is indeed something that was possible on ReactJS before, but not with packet size as small as the one VueJs offers.\n\nThere are some disadvantages named in Vuejs like a language barrier because a big amount of users come from China or the way it works to enable reacting to data changes.\n\nThose are all valid points that can be overcome by time or learning to handle data right.\n\nOne of the things that I personally don't like about Vue is its syntax when handling variable inserts in the HTML.\n\n```html\nCick Me \n```\n\nIn the example above you see one of those cases. The URL this Link referees to depends on the language of the user it either goes to [https://someUrl.com/en/subPath/](https://somehtml/en/subPath/) or [https://someUrl.com/de/subPath/](https://somehtml/en/subPath/) \n\nThe colon in front of the href tells Vue to see this as some javascript code. The data entered still has to be inside of quotes. This creates this weird case where you use 3 different quotes to add the data.\nIt's not something that is all too bad and can be avoided by calculating the link in a function and then adding it into the HTML afterward but sometimes it's faster for someone else to understand if the intended URL is directly in the line where it is used.\n\n### Svelte\n\nAfter talking about bigger players around let's start to mention the underdog.\n\nSvelte is a framework created in November 2016. The idea behind it created out of the question:\nWhy should all the work of creating responsive pages move towards the frontend, if it could be done way better in the backend?\n\n![svelte_meme.jpg](/uploads/svelte_meme_c568d947e5.jpg)\n\nThe size of javascript, although all the efforts of keeping it as small as possible, are still pretty high in other frameworks compared to Svelte. In fact, Svelte is actually not a framework but merely a compiler that generates smaller bite-sized packages of code.\n\nThis enables package sizes that are smaller than seen before. The browser only needs to download the parts that it needs to display and keep the rest to the server.\nThis enables other advantages like a build-in prefetching of Data on the serverside and only fetching the data on the frontend if it is dynamically changing data. This makes websites created with Svelte have incredibly fast load times and respond almost instantly.\n\nAlso svelte has the advantage of learning from existing frameworks that enables certain things like a store or transitions out of the box.\n\nBy precompiling .svelte files in the backend, also enables a better syntax that Vue sometimes has trouble with. (For more info on the syntax go ahead and see the other posts of this series.)\n\nVueJS has its disadvantages. One of the biggest being that it is still actively being developed and in the future might encounter some breaking changes in its updates. The svelte team also already confirmed some breaking changes in the near future which make the current framework for delivering vueJS websites (sapper) obsolete.\nThe team already promised a guide to transition from sapper to the new changes but this still means work to keep things up to date.\n\nThe other biggest disadvantage is that Svelt other than React or Vue is not developed with the thought of placing it into existing sites as subelements.\n\nI would currently only Recommend Svelte over the other frameworks if you are starting a new project from scratch and are ready to take some effort when it comes to updating to newer versions when the svelte team brings out new updates.\n\n## The Backend\n\nNow that I talked about how we are going to display the content to the user the next point to think about is how to make it as easy as possible for the owner of the website to edit the content.\n\n### Strapi\nAs a developer, it's possible and easy to just change the source code and make a new deployment. This is something that many non-tech people couldn't do.\n\nThe usual way to do this is by using a CMS like WordPress. This means buying a template or creating one on its own, and most of the time ending up with something that has less optimized load times and lacks reactiveness which makes a modern website feel great.\n\nHere comes Strapi into play. Strapi is an open-source headless CMS. Headless means that it does not offer any frontend. Strapi allows creating content and content types without any code. Strapi then creates express endpoints that the user can directly access to get the data. Those Endpoints can be easily modified to change the value the user gets as a result or send an email to the user as a response to an action. In my case, I used it to receive notifications whenever someone uses the contact form and saves data in my database.\n\nAnother great feature that strapi enables is build-in support for graphQL to fetch the exact data that you need instead of extra data that just slows down the request\n\nIn the later parts of this series, I will talk about how I set up strapi and made it communicate with my Svelte application.\n\n### Nginx\n\nTo be able to make this communication work the tool used is called Nginx which is a free and open-source tool to enable reverse-proxies, load balancing, and even caching. In my case, I use the reverse proxy capability to change the requests going to my server to the right ports of either strapi or the svelte application. This can also be used to enable load balancing to multiple servers to ensure that with increasing requests the servers will still be able to stand under the load.\n\n# Whats Next?\n\nI hope you enjoyed this post. If it made you curious about the way it is implemented then you can go to the [next post](/blog/svelte-strapi-nginx-2) where I will start explaining how to implement the Frontend using Svelte and Sapper.","authorUrl":"/about","tags":["Svelte","Strapi","Nginx"]}]}