DEV Community: Alex Pustovalov

A Handy Tip for GitHub Pages Custom Domains

Alex Pustovalov — Sun, 29 Dec 2024 17:23:07 +0000

Have you heard about GitHub Pages?

You probably know that GitHub offers free hosting for technical websites via GitHub Pages.

But did you know about a useful feature GitHub Pages provides for organizations?

Here’s how it works:

Create an organization on GitHub.
Navigate to the organization’s settings and find the Pages section.
Add your custom domain there and verify it by following the provided instructions.
Create a repository named .github.io in the organization, where is your organization’s name.
Go to the repository settings, find Pages, and set the same custom domain you verified earlier.

That’s it! From now on, all GitHub Pages repositories you create within this organization will automatically use your custom domain. No need to manually configure the domain for each repository!

I’ve used this setup for a site where I plan to showcase my collection of websites built with TileDocs. https://hub.tiledocs.com

It’s a neat and efficient way to manage custom domains for multiple projects. Give it a try!

Building A Robust Web Platform on AWS: Using Remix in AWS Lambda

Alex Pustovalov — Fri, 15 Dec 2023 14:09:08 +0000

In today's deep dive, I'll be unpacking my journey of deploying Remix on AWS, specifically as a Lambda function.

For the tech aficionados, dive into the code details in our web platform's repository here: https://github.com/pagemosaic/pagemosaic-web-platform

Remix Handler

Let's cut through the jargon: Remix is versatile enough to run on various JavaScript runtimes, making it a perfect candidate for AWS Lambda functions.

Here’s the catch: Remix typically nestles within an HTTP server to handle requests. This requires a specialized adapter to interface with various HTTP servers. So, in a Lambda environment (essentially a JavaScript runtime container), we leverage an HTTP server to fetch web pages as responses.

In a turn away from conventional servers like Express, I opted for Remix's native solution – the Remix App Server. However, Lambda's distinct request handling interface necessitated a custom adapter for effective Remix integration.

Remix Adapter

The Remix library does offer an AWS Lambda adapter. Yet, it's tied to a framework I sidestepped: AWS Architect, known for orchestrating Lambda microservices and S3-backed websites.

So, I extracted the crucial elements from the adapter’s code, creating a bespoke module – the web-adapter – in my project.

Remix Web Application

What's next? Developing the web application module itself using Remix. Given my preference for Vite or Rollup for module compilation, Vite was my go-to for bundling the web application.

Here's a twist for Remix web applications: they require dual bundles. One for the client side (sans server-executable code) and another for the server side.

Thus, the build command for the web application module aligns as vite build && vite build --ssr. Peek into the web-app module's code in our GitHub repository.

Bundle All

Now, deploying the server-side bundle on AWS as a Lambda function means integrating it with the custom web-adapter module.

This led to introducing Rollup with a configuration merging dependencies from both modules, resulting in a Lambda-ready JS runtime bundle.

The final build command for my web application stands as vite build && vite build --ssr && NODE_ENV='production' rollup -c rollup.config.mjs.

But it’s not just about code. I tweaked the Remix directory structure for a streamlined deployment process – separating the server part as a Lambda function and the client part as static files in an S3 bucket.

Deployment

The next phase involved crafting CDK constructs for Lambda function creation and HTTP endpoint setup for the web application, alongside another construct for deploying the client's static files.

You can unearth these construct codes in the infra module files: web-app-api.ts, system-bucket.ts, system-bucket-deployment.ts. Strategically, these are split into distinct constructs for tailored resource initialization sequences on AWS.

Entry Point

Finally, I assembled a construct for creating a CloudFront distribution with varied access points for both the web application and static resources. Find this code in enty-point.ts in the infra module.

That wraps up my Remix utilization saga for our web platform. Keen on taking it for a spin? The launchpad awaits in the readme of our source code repository: https://github.com/pagemosaic/pagemosaic-web-platform.

Follow Alex Pust on Twitter for updates on the Page Mosaic Web Platform development.

Building a Robust Web Platform on AWS: Deploy the website to AWS using the CDK.

Alex Pustovalov — Mon, 20 Nov 2023 13:41:48 +0000

In my previous post, I discussed adding a user to manage AWS resources via the command line.

This user can also manage resources using the AWS console.

At this stage of development, my plan was to create infrastructure for deploying a static webpage for a website on AWS.

Basic setup

Now, I will discuss the basic structure of the project, which I intend to develop gradually.

It's important to note that the code will be primarily written in TypeScript, with some JavaScript.

Since the project involves multiple modules, I chose the pnpm package manager, known for its efficiency in multi-module projects or monorepos.

Setting up pnpm is straightforward. First, create a package.json file, add the workspaces option, and list the directories containing your module code.

I placed all modules in the platform directory and thus specified it in workspaces:

“workspaces”: [
    "platform/*"
]

Additionally, I created a pnpm-workspaces.yml file, also specifying the module directory:

packages:
    - 'platform/*'

Website module

Next, I started creating the modules. For the website module, I created platform/web-app. Despite the name, this directory will eventually host a web application on remix.run, not just a static site.

In platform/web-app, I added an index.html page for my website.

Infrastructure setup

Following this, I began creating the AWS infrastructure for the website.

I started by installing the AWS CDK Toolkit:

npm install -g aws-cdk

Then, I created platform/infra, inspired by the Astro aws-astro adapter library. I used the following command to generate CDK code:

cdk init sample-app --language typescript

Reference: CDK Workshop

I customized the generated code and file names, resulting in a specific directory structure.

Let's briefly discuss how the CDK works. It's a toolset for defining AWS cloud infrastructure in code, like TypeScript. This code compiles into CloudFormation stacks, which AWS uses to create the required infrastructure.

CDK mainly deals with two objects: Construct and Stack. A Construct can contain several other Constructs, while a Stack, responsible for generating the CloudFormation stack, can also contain several Constructs.

This approach simplifies describing infrastructure as a tree.

Infrastructure construction

Inside src, I created constructs for CDK Constructs and stacks for CDK Stacks. I then created a PlatformStack class in src/platform-stack.ts and a WebsiteConstruct class in src/website-construct.ts for the website's infrastructure.

WebsiteConstruct manages the S3 Bucket (without public access), access rights, a CloudFront distribution, and uploads the contents of platform/web-app to the bucket.

For deployment, I used bin/infra.ts, executed by the CDK Toolkit.

The cdk.json file specifies the path for bin/infra.ts:

"app": "npx ts-node --prefer-ts-exts bin/infra.ts"

Deployment is initiated using:

cdk deploy

Deployment specifics

For first-time AWS deployments, bootstrapping CDK resources in your account is required. This is a one-time process, with additional bootstrapping needed for new regions.

I aimed to integrate deployment commands into the project's build flow. To avoid writing OS-specific scripts, I created JavaScript files for bootstrapping, deploying, and destroying the AWS stack, and included them in package.json.

Run deployment

User authentication in AWS before running these commands is crucial. I developed a run-command module for authorization checks and setting AWS session credentials in process.env.

This module reads from a .env file at the project root, containing the AWS administrative user's name and deployment region.

Scripts in package.json can now be executed through run-command:

run-command node ./scripts/deploy.js

To manage the build and launch various modules in sequence, I added the turbo tool to the project.

The entire project code at this stage is available at PageMosaic GitHub in the stage-1 branch.

While the setup may seem basic, it provides a fundamental understanding of AWS infrastructure deployment and programming simplicity, avoiding complex AWS console manipulations.

You can try deploying this single-page site on your AWS by following the instructions in the repository's README.md.

In my next post, I'll describe replacing the static webpage with a full-fledged web application on remix.run.

Building a Robust Web Platform on AWS: A Step-by-Step Journey Through AWS CLI and IAM Identity Center

Alex Pustovalov — Sun, 19 Nov 2023 13:30:15 +0000

This article continues the story of creating the Page Mosaic Web Platform project.

I have already created an account on the AWS platform. It's not difficult, everything is done quickly. However, before using CDK to create or configure anything on AWS, it's necessary to set up a user with administrative rights and programmatic access to resources.

This means that I don't want to use the root user on my AWS account for manipulating resources. I'm already experienced in this.

Therefore, I enabled IAM Identity Center on my AWS account. As far as I understand, this is a new mechanism for user management, and AWS recommends using it instead of managing IAM users individually.

First, I created a user in IAM Identity Center as described in the instruction at https://docs.aws.amazon.com/singlesignon/latest/userguide/get-started-use-identity-center-directory-create-user-in-identity-center.html.

Then, I added administrative rights to the permission set in my IAM Identity Center, following the instructions at https://docs.aws.amazon.com/singlesignon/latest/userguide/get-started-create-an-administrative-permission-set.html.

And finally, I linked the administrative rights to the user in my account, as outlined at https://docs.aws.amazon.com/singlesignon/latest/userguide/get-started-assign-account-access-admin-user.html.

Now, I needed to check if I could connect to AWS from the command line because I would be running CDK scripts from there.

I installed AWS CLI on my MacBook, following the instructions at https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html.

Next, I needed to configure my user's access. First, I set up the user configuration on my local computer by running the command:

aws configure sso —profile [user name]

I used the profile option to separate different user configurations on my computer.

Then I specified the session name, which the session token, issued for a certain duration when the user works with resources from the command line, would be linked to.

Next, I authorized on the website in the browser and completed the required forms. The terminal itself opened the browser, and I went through the authorization process.

Step 1:
Step 2:
Step 3:
Step 4:
Step 5:

After successful authorization, I returned to the terminal window and specified the region the user would use and the default format.

After that, I could already execute commands like:

aws s3 ls --profile sitebud-admin

In the next post, I will create the initial structure of the codebase of the platform project and add CDK scripts for deploying and configuring resources for a static website on AWS.

Building a Robust Web Platform on AWS

Alex Pustovalov — Sat, 18 Nov 2023 21:36:18 +0000

In this post, I'm starting a series where I will share my progress on an ambitious system project. The project is a comprehensive, open-source web platform offering a range of features like subscription and membership management, email communication, payment processing, and file storage, all hosted on Amazon Web Services (AWS).

The project is called Page Mosaic. The name doesn't fully reflect the system's purpose, but other names I considered were already taken.

I plan to develop a system that can be launched on AWS, utilizing its resources to the fullest.

AWS is an excellent platform for creating the backend of any online service. It's affordable, flexible, and complex.

Launching a container or a server instance on AWS is straightforward. However, setting up the system for automatic scaling based on load is complex and requires a deep understanding of how AWS works.

In this project, ChatGPT will be a valuable tool that I'll use extensively.

To deploy the system on AWS without delving too deep into the AWS console, I'll use the Cloud Development Kit (CDK).

CDK allows you to script nearly all the administrative tasks for creating and configuring AWS resources.

CDK is a very powerful tool, comparable to having an excellent AWS dev-ops on your team.

Currently, my task is to create a web page or website to host a landing page for the project, drawing attention to it.

I'm doing this as part of the project development because the site will run on this system, making it the foundational element of the system. The system's site will run on the system itself – it makes sense to use what we build.

In my next post, I'll detail how I'm doing this. As a teaser, the site will run on Remix.run and will be entirely serverless.

Create an admin panel full-stack app for your database in minutes.

Alex Pustovalov — Sat, 28 Aug 2021 12:44:41 +0000

If you store information in a relational database, I bet you wish you had a handy application through which you could view or edit that data. Then, as far as I can guess, you started making this app or even made it.

In any case, if you've ever created an application for working with a database, you know that it's not easy at all.

You have to choose a technology stack. Then you have to design the architecture of the application to ensure security, speed, and accuracy of data, etc.

Fortunately, there are already numerous frameworks and libraries that can be used as building blocks for full-stack applications.

But still, writing and debugging code takes a lot of time. Even if you are a very experienced software engineer.

So we decided to create a tool that would generate application code for your database using these "blocks". We wanted to make the generated source code usable right out of the box. If not, you could use it as a seed for your own application.

And we did it! Meet IKODIX, an online source code generator for full-stack applications.

IKODIX does not require access to your database to generate code. It uses a declarative approach.

I hate to give a long and tedious description of IKODIX - let's go straight to creating a small application. This should take you no more than 50-60 minutes.

Even if you already have some test databases available, let's run the MySQL database in Docker to speed up the process.

Run the database

Install Docker Desktop on your localhost. We need it not only to run the database but also to run the generated application.

Create a todo-db directory, go into it, and create a docker-compose.yml file
Copy the following code into this file

services:
  db:
    image: mysql:8.0.19
    volumes:
      - ./data:/var/lib/mysql
      - ./init.sql:/init.sql
    restart: always
    environment:
      - MYSQL_ROOT_PASSWORD=root_password
      - MYSQL_DATABASE=todo
      - MYSQL_USER=myuser
      - MYSQL_PASSWORD=mypassword
    expose:
      - 3306
    ports:
      - 3306:3306
    command: --init-file /init.sql

Create an init.sql file and copy the following code into it

CREATE DATABASE IF NOT EXISTS todo;
USE todo;
DROP TABLE IF EXISTS `employee`;
CREATE TABLE `employee` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `full_name` varchar(1000) NOT NULL,
  PRIMARY KEY (`id`)
);
DROP TABLE IF EXISTS `task_status`;
CREATE TABLE `task_status` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `status_name` varchar(200) NOT NULL,
  PRIMARY KEY (`id`)
);
DROP TABLE IF EXISTS `task`;
CREATE TABLE `task` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `description` varchar(5000) NOT NULL,
  `to_date` date DEFAULT NULL,
  `assignee_id` bigint DEFAULT NULL,
  `status_id` bigint NOT NULL,
  PRIMARY KEY (`id`),
  KEY `task_employee_id_fk` (`assignee_id`),
  KEY `task_task_status_id_fk` (`status_id`),
  CONSTRAINT `task_employee_id_fk` FOREIGN KEY (`assignee_id`) REFERENCES `employee` (`id`),
  CONSTRAINT `task_task_status_id_fk` FOREIGN KEY (`status_id`) REFERENCES `task_status` (`id`)
);

Create another data directory inside the todo-db directory
Run the command in terminal: docker-compose up -build
Wait until the container reports that it is ready…

You now have a Docker container running on your computer with the todo database. It contains 3 tables: employee, task, task_status.

Open IKODIX

We can start describing tables in IKODIX. Open IKODIX. Go to Data Tables, and add tables with columns as described below.

employee table

Add the employee table. By default, it will already have a mandatory Primary Key column with type Long and name id. This is fine for us because the real table employee has a primary key column named id. This applies to all other tables in our database.
Add full_name column with String type.

task_status table

Add the task_status table.
Add the status_name column with the type String.

task table

Add the task table.
Add the description column of type String.
Add the assignee_id column of Long type.
Add the status_id column as a Long.
Add the to_date column of type Date.

Once we have a list of tables we can start creating projections.

A projection is data from some linked tables. This data will be displayed on the front-end on a separate page in the Data Grid. You can make an analogy with the SQL query that you write to select some records from the database.

As you may have guessed, our database contains information about some tasks. The first thing we need to see is all the tasks and the employees assigned to them.

Create the Task projection.

A diagram will open in front of us, where we need to add tables that we want to see records from.

We will add the task table first. The first table is the root table in the diagram and we will link the other tables to it. This is very similar to how we write a SQL query.

Let's add the task_status table. Link the status_id column from the task table to the id column in the task_status table.

Add the employee table. Link the assignee_id column from the task table to the id column in the employee table.

Let's go to the View tab. Here we should mark as Visible all columns from the tables in the diagram, which we want to see on the front-end.

Mark the description and to_date columns from the task table. Set any suitable names for these columns in the Grid Column Title.

Set visible the full_name column from the employee table, and the status_name column from the task_status table. Give them names, too.

You can rearrange the order of the columns that will be displayed in the Data Grid.

Next, go to the Create tab. On this tab, we configure the form for creating a record for the root table in the diagram. That is, the record will be created only in the task table.

Let's mark description and to_date fields as visible, give them names and corresponding field types.

But besides these fields, we have linked fields with other tables: assignee_id and status_id. Let's mark them as visible, name them, and choose Select type.

Once we mark them as visible, we have the option in the Select Control Settings section to customize the drop-down lists. We can specify the column from the linked table that will be used for the names in the drop-down list.

Select the status_name column for status_id, and the full_name column for assignee_id.

Go to the Update tab and do the same as in the Create tab.

We have the first projection ready. Now IKODIX will be able to generate an application where we will have a page with all the tasks and the employees assigned to them. And we will be able to add tasks through the input form.

But we don't have a page and input form to add employees to the list. In addition, there is no page and form for entering job statuses.

This is easy to fix. Create two projections for employees and for statuses: Employees and Statuses. Add to each projection one table on the diagram: employee and task_status, respectively.

It would probably be preferable if you try to configure Data Grid and forms in the tabs View, Create and Update for each projection by yourself.

When you have completed all the settings in the new projections, we can start generating the source code for the application.

Generating the source code

But there is one more thing not finished - we need to choose the type of database MySQL. Let's go to the System Settings section and set the database type we want.

Click the Download Source Code button and name the application something like "ToDo Admin".

Save the archive to the localhost in the empty todo-app directory. Unzip the archive in this directory.

Now we can get started with our application. We don't need to install anything extra to start the application.

Open the README.txt file and read carefully what is written there.

According to the manual, there are two modes of running the application: demo and dev.

Demo is when a ready-to-use application is built and run.

Dev is when the application is launched for development. The Hot Reloading for the front-end works in this mode.

Let's run the application in demo mode to see how it works out of the box.

Before we start, we need to configure access to our database. This can be done in the .env file. Find there the variable dataSource.url and replace its value with jdbc:mysql://host.docker.internal:3306/todo. Then replace the username (dataSource.username) with myuser and the password (dataSource.password) with mypassword. Save the file.

Running the application

Two Docker containers are used to run all the parts of the application. But all we need to do is run the command app.sh demo (or app.cmd demo for Windows). And wait for the application to start.

Since the containers with the application run in the background, we need to keep track of them. Let's run the two commands app.sh client-log and app.sh service-log in separate terminals.

Once we see that everything is up and running, we can open the browser with the address http://localhost:3030

There is one user with administrative rights by default in the system. So we will log in under his account, username: administrator, and password: administrator_password.

There are no records in our tables, so let's try to get new employees, new statuses, and create tasks.

Even though the app works out of the box, we need to change the company name in the upper left corner.

In order to do this, let's run the application in development mode. Simply run the command app.sh dev.

Let's wait for all Docker containers to start. To ensure that they are ready, use the commands: app.sh client-log and app.sh service-log in separate terminals.

When ready let's open the browser with the address http://localhost:3030

Now, find the WorkspacePage.tsx file in the front-end code in the to-do-admin-client/src/features/layout directory, and replace the text "Company Name" with the value we need: "ToDo Admin".

Save the changes in the file.... and see the page in your browser. The value should automatically change.

Docker containers for the front-end are made so that Hot Reloading works.

After the final changes you need to run the app.sh demo again - then the parts of the application will be built for use in the production. You will find the distributions in to-do-admin-client/build and in to-do-admin-service/target.

If you are going to extend the functionality of the application, first read the README.md files with a detailed description of the code structure in the to-do-admin-client and to-do-admin-service directories. This will help you to understand the code without difficulty.

I hope you are not too tired and enjoy building with IKODIX. In any case, it is much faster and more comfortable than developing such applications by yourself.

If you have any comments or questions, do not hesitate to post them on our forum: IKODIX forum

Also follow new IKODIX releases on our Twitter account: @kodix