NextLink Labs, with an office in Pittsburgh, is a consulting and technical execution company founded by developers

NextLink Labs

Django 3.1 was recently released and along with it came support for asynchronous views. To anyone that uses Django and works with lots of data from lots of different Web sources, this is a big deal. Supporting asynchronous views means cleaner code, a different way to think about things, and most importantly, the ability to dramatically improve performance of applications. But let’s back up a bit. If you’re unfamiliar with the term “views”, don’t worry, it’s an easy concept to understand. Views are key components of applications built-in with the Django framework. At their very simplest, views are Python functions or classes that take a web request and produce a web response. Prior to Django 3.1, views had to run with Python threads. Now, views can run in an asynchronous event loop without Python threads. This means Python’s asyncio library can be used inside of Django views. According to the : documentation The main benefits are the ability to service hundreds of connections without using Python threads. There are other benefits as well including the use of Python’s . asyncio.gather Let’s say you have a view that makes four API calls. Even in a best-case scenario, if each call takes only a second, it’s a total of four seconds if executed synchronously. And that’s the best-case scenario. We can cut down on that time frame significantly and improve the situation overall by using Pythons concurrent.futures library. This makes it possible to make the four API calls in the previous example concurrently meaning the view could take roughly one second in total if using four workers with the ThreadPoolExecutor. By all accounts, the practice cuts down on the time needed and improves the calls. That’s important in a world where seconds matter and making someone wait around for an application to load can cause frustration. A Real-World Example: Tracking Montana's Yellowstone River To illustrate how asynchronous views improve performance, I created an example project to display statistical data from the . United States Geological Survey (USGS) The project makes six API calls to the USGS to collect data about six access points on the Yellowstone River in my home state of Montana. This data includes the volume of water moving at each access point at the time, known as discharge rate, as well as the gage height, or stage, which is the surface level of the water relative to its streambed. Example 1: The Synchronous Method Code: response = requests.get( )
  data = parse_flow_and_height_from_json(response.json()) data start_time = time.time()

  river_data = [] site_id SITES.keys():
      river_data.append((SITES[site_id], get_river_flow_and_height(site_id))) render(request, , { : river_data, : , : time.time() - start_time,
  }) : def get_river_flow_and_height (site_id) """
  Synchronous method to get river data from USGS
  """ f'https://waterservices.usgs.gov/nwis/iv/?format=json&sites= &parameterCd=00060,00065&siteStatus=all' {site_id} return : def dashboard_v1 (request) """
  Synchronous view that loads data one at a time
  """ for in return 'rivers/dashboard.html' 'river_data' 'version' 'v1' 'load_time' Result: The data loads and takes almost four seconds. For the purposes of this post, that’ll be our baseline. Let’s see if we can improve that situation. Example 2: A Concurrent View Loading Some Data Simultaneously start_time = time.time()

  river_data = [] concurrent.futures.ThreadPoolExecutor(max_workers= ) executor: site_id, data zip(SITES.keys(), executor.map(get_river_flow_and_height, SITES.keys())):
          river_data.append((SITES[site_id], data)) render(request, , { : river_data, : , : time.time() - start_time,
  }) : def dashboard_v2 (request) """
  Concurrent view that loads some data simultaneously
  """ with 3 as for in return 'rivers/dashboard.html' 'river_data' 'version' 'v2' 'load_time' Result: Now we’re down to roughly 1.5 seconds and that’s a big improvement. Let’s see what happens when we leverage asynchronous views. Example 3: The Asynchronous Method httpx.AsyncClient() client:
      response = client.get( )
      data = parse_flow_and_height_from_json(response.json()) data start_time = time.time()

  river_data = []

  datas = asyncio.gather(*[get_river_flow_and_height_async(site_id) site_id SITES.keys()]) site_id, data zip(SITES.keys(), datas):
      river_data.append((SITES[site_id], data)) render(request, , { : river_data, : , : time.time() - start_time,
  }) async : def get_river_flow_and_height_async (site_id) """
  Asynchronous method to get river data from USGS
  """ async with as await f'https://waterservices.usgs.gov/nwis/iv/?format=json&sites= &parameterCd=00060,00065&siteStatus=all' {site_id} return async : def dashboard_v3 (request) """
  Asynchronous view that loads data using asyncio
  """ await for in for in return 'rivers/dashboard.html' 'river_data' 'version' 'v3' 'load_time' Result: Wow, we got results back in just under a second. That’s roughly a three-second improvement on the original method. This example shows pretty clearly how asynchronous views can be leveraged to drastically improve performance. This is just a small example of the performance improvements we see on a daily basis with the projects we work on at . NextLink Labs View the full project on GitLab: https://gitlab.com/nextlink/example-django-async-rivers Previously published at https://nextlinklabs.com/insights/django-async-views-improves-API-calls

How to Improve Django 3.1 View Performance with Async Support

Rails version 1.0 is approaching its 15 year anniversary, and there’s reason to celebrate the framework's progress. There have been hundreds of amazing products built with Rails since its creation. Streaming service heavyweight , project management leader , and hospitality service were all built using Rails. Hulu Basecamp AirBnB But for every successful project, there’s dozens if not hundreds of others that are overloaded with technical debt, difficult to manage, or a cumbersome nightmare to improve. As software consultants, we here at are often tasked with taking over these kinds of legacy Rails apps that have been abandoned by their previous development teams. We’ve been down this road plenty of times before and we understand what a problem they can be for developers. NextLink Labs But we’re also developers ourselves so after dealing with several of these projects, we created a step-by-step guide that we use when starting one of these projects. Here’s our roadmap for successfully taking ownership of a legacy Rails project. 1. Code Review and Local Setup Documentation Overview When starting with one of these abandoned Rails projects the first thing we do is try and understand the state of the app, namely the code complexity and the level of technical debt. If you’re unfamiliar with the term “technical debt”, it is the result of development teams taking shortcuts to expedite the delivery of a feature or a project. If you’ve ever blown through something “just to get it out the door” and felt somewhat uncomfortable with it, you’ve felt the pang of “technical debt”. Every project inevitably takes on some amount of technical debt during its lifetime, so taking stock of code complexity and gauging the level of technical debt is a critical first step. First, scan high and low for any written documentation about the project, whether it be a README, a wiki attached to the git repo, or some other documentation for the project. Next, check the Gemfile and Gemfile.lock for the number of dependencies and Rails/Ruby versions being used. While doing this, be on the lookout for any gems you aren’t familiar with and make sure to research what they do. We usually write a quick note next to every gem to avoid having to visit rubygems constantly for reminders. Test Review After reading any available documentation, the best starting point for a code review is by looking at the tests in the spec/ or test/ folder. Tests are the backbone for any Rails project and they are even more important when upgrading or refactoring a project. If the project has no tests or if it has low test coverage, then that'll be the first place we start writing code after finishing the code review. (We’ll cover getting to 100% test coverage later in this post.) Review Routes and Database Structure Next, check the config/routes.rb file and the db/schema.rb file. These files give us an idea of how the data is organized and how the app flows. We make a note inside the schema definition of any "god objects" (i.e. database tables with ~30 or more columns) that could be targets to be divided up down the road. In the routes file, we make notes of any controllers that have large numbers of custom actions outside of the standard REST actions. Another aspect of the routes we note is the number of only: or except: modifiers on resources definitions. If we don't see only or except anywhere in the routes file, that most likely means we're dealing with lots of unused routes that we'll want to prune. s Review Remaining Folder After looking into these three areas, we quickly scan the files in the app folder. If the app has any complexity to it at all, it will be unrealistic to develop a full mental model of the project at this point, so we’re not going to do a line-for-line review of every controller, model, or view. Instead, we're looking at general code quality, making notes of any giant files of 200 lines or longer, and any other red flags such as activerecord callbacks with lots of implicit behavior, no strong parameters inside controllers, etc. There are many automated tools that can help with this, and we use the often to give us an idea of the overall code quality. Rails best practices gem 2. Write Tests Up to (Ideally) 100% Test Coverage At this point, you should have a decent understanding of the project. You probably won’t have a complete mental picture of the project but you’ve made some progress, so we'll circle back to the tests and the test coverage. In our experience, a high-quality test suite is extremely rare in the realm of inherited projects. In fact, the norm for inheriting projects will most likely involve situations that have no tests at all or at the very best, test coverage between 10% and 20%. When given a low-quality test suite, the first thing to do is just start adding as many tests as possible to get as close to 100% test coverage as you can. This is obviously easier said than done, and we often spend several weeks at this stage; however, without an adequate test suite making any code changes later will be incredibly dangerous. We don't try to get fancy with our test suite. We write simple unit tests for model and service object methods, add integration tests for every controller route, and typically 5-10 feature tests of the app's core functionality to make sure all the pieces work together. There's a lot of discussion in the Rails community if 100% test coverage should be a target for a test suite. For this kind of special case, we do believe that 100% coverage is important because it helps with catching many small edge case bugs when refactoring down the road. If you need assistance with visualizing test coverage, look into the simplecov gem which creates a nice HTML table to see what code paths your tests are taking. 3. Review Deployment and Setup Staging Server With the code reviewed and a reliable test suite backing us up, the last thing we review is the deployment process. In the best case, the README or the client has a step-by-step guide for how to deploy to production and to staging. Realistically, we don’t live in this world. You’ll rarely encounter intensely documented README files, so the deployment practices you encounter will probably be unclear in most scenarios. Or there’s nothing and you have no idea. That happens. Mapping out the deployment process in cases without a lot of direction mostly involves relying on your experience and a healthy dose of guess work. As you record each deployment step, make notes on possible errors that could happen and develop a strategy of how you would revert the step or handle the error. It’ll take a little work. Want to get some help mapping out the deployment process and get some small amount of reassurance for future production deployment? Do this: Spin up a free Heroku dyno and push the project up there to check for errors and how the app performs. 4. Lint Codebase with Rubocop and Prettier With the review phase done, we can now start moving into code changes. Start off low stakes with some automated linting tools that should cause no behavioral changes to the code, specifically rubocop and prettier. Even with these popular libraries, there's always a chance of bugs which is why we only start making these changes when we're confident in our test coverage. While there are some variations, our standard linting process is three steps. We start by running rubocop --auto-correct which automatically corrects any safe formatting warnings. Then we use the prettier gem and run rbprettier --write '**/*.rb' to fix other remaining formatting issues, specifically any line length warnings. Finally, we run rubocop --auto-gen-config which will create a rubocop_todo file to record all remaining rubocop warnings which we can begin fixing right away or later on. Having this rubocop_todo.yml file will make sure we're not introducing new formatting errors when we make other changes in later steps. As a side note, at NextLink Labs, we're big fans of using the git blame command when trying to understand what's happening with specific code sections, and having large formatting changes like the ones generated by rubocop and prettier can make git blame less useful. However, git has an ignore-rev flag for ignoring exactly these kinds of commits, and we recommend adding formatting commits to a .git-blame-ignore-revs file and following a to automatically ignore these commits. guide like this 5. Deploy to Staging and Production As we noted above, the formatting changes we made in the previous section should (theoretically) not affect behavior at all, so we can take this opportunity to test our deployment process. The first production deploy is by far the most dangerous step of the entire process, but we eventually have to take it, so we try and get it out of the way now. If the project has no staging environment, now’s the time to set one up. It’s important to have a staging environment that mirrors how the production environment is deployed. For example, if the project uses capistrano for production deploys, spin up a new AWS server and test a capistrano deploy to that endpoint. You should always test reverting for different possible errors on this staging server and test to make sure the website itself is working correctly after it's launched. At the end of the day, there's only so much to prepare for your first push to production, so always aim for a low traffic time, and then pull the trigger with all hands on deck in case of emergency. 6. Upgrade Rails, Ruby, and Gem Versions Once our first deployment to production has gone smoothly, we begin with the (potentially) breaking changes. This can take different forms depending on the project. In some cases, you’ll have product owners that will ask for upgrades to a specific Rails version or Ruby version. In other cases, clients leave it up to your best judgement. Upgrading both Ruby and Rails versions are entire blog posts in and of themselves, but to offer a bit of direction, just take it one minor version at a time and rely on your tests for guidance if something breaks. Since Rails 5.0, there have been significantly less breaking changes, but upgrading even a minor version between Rails 3.0 and Rails 5.0 can require major code changes, so slow and steady is the key to avoid introducing new bugs. More Refactoring Or New Feature Development With our target Rails, Ruby, and gem versions safely deployed to production, you’ll have finished the foundational work. Well done. Depending on your client, this may be the end of the project -- all that’s required is an upgrade to their gem versions. Most of the time though, there's a list of features to go along with the changes. With these 6 steps finished, you’re now in a much better position to start this feature development. Happy development!

6 Tips for Taking Ownership of a Legacy Rails Project

If you're reading this, you probably know what a CI/CD pipeline is. If you don't, no big deal -- it's just yet another acronym. CI/CD short for "continuous integration and continuous delivery", which when we boil it down, simply means that everything between your git commit and a deployment works auto-magically so you can rest your fingers and watch some Netflix. In this example, I'm going to be focusing on deploying a static HTML website, but you really could do this for any sort of web application front-end. We will be highlighting how to do this using AWS, Terraform and Gitlab. Let me just explain real quick why we'd want to do this. First, this makes your life easier. You write the code, you make a commit, push, and your pipeline deletes old files from your S3 bucket, uploads the new files, sets permissions, and then invalidates your CloudFront distribution so that all you have to do is go look at your changes in production. Second, it removes human error. You can't forget to upload files or invalidate a CF if your code does it for you. Third, it speeds up your deployments because you no longer have to go ahead and do things manually. For all of these reasons, I always set up a pipeline for all of my personal and professional projects. Enough of me rambling; let's get to work. Prerequisites A account GitLab An account AWS is installed Terraform A account Keybase Set up the infrastructure I like to make things as easy and reproducible as possible, so we'll be using Terraform to build out the infrastructure. If you don't have Terraform installed, then you didn't read the prerequisites (tsk tsk...) and I'm going to need you to install it. For the website's infrastructure, all we'll need is an S3 bucket and a CloudFront distribution. We'll just use a default CloudFront certificate since we aren't connecting this distribution to our domain name in this example. Before we go any further, I would recommend creating a repository for all of your Terraform configs. It will just keep things more organized if you decide that you want to continue to use Terraform for configuring your infrastructure. Anyways... Create a file named main.tf and paste this into. You can change the bucket_name variable to whatever you want, just make sure you set this correctly later on in another file (you'll see as I've highlighted where it needs to be adjusted in the code snippet). {
  default // provider region }

resource bucket acl policy { : , : [
      { : , : , : , : , : }
  ]
}
EOF

  website index_document error_document }
}

locals s3_origin_id }

resource origin domain_name origin_id }

  wait_for_deployment enabled is_ipv6_enabled default_root_object default_cache_behavior allowed_methods cached_methods target_origin_id forwarded_values query_string cookies forward }
    }

    viewer_protocol_policy min_ttl default_ttl max_ttl }


  price_class restrictions geo_restriction restriction_type }
  }

  custom_error_response error_code error_caching_min_ttl response_code response_page_path }

  viewer_certificate cloudfront_default_certificate }
} variable "bucket_name" = "website.example.com" change this} "aws" { = "us-east-1" "aws_s3_bucket" "bucket" { = "${var.bucket_name}" = "private" = <<EOF "Version" "2012-10-17" "Statement" "Sid" "AddPerm" "Effect" "Allow" "Principal" "*" "Action" "s3:GetObject" "Resource" "arn:aws:s3:::${var.bucket_name}/*" { = "index.html" = "index.html" { = "S3-${var.bucket_name}" "aws_cloudfront_distribution" "s3_distribution" { { = "${aws_s3_bucket.bucket.bucket_regional_domain_name}" = "${local.s3_origin_id}" = false = true = true = "index.html" { = [ "DELETE" , "GET" , "HEAD" , "OPTIONS" , "PATCH" , "POST" , "PUT" ] = [ "GET" , "HEAD" ] = "${local.s3_origin_id}" { = false { = "none" = "redirect-to-https" = 0 = 3600 = 86400 = "PriceClass_100" { { = "none" { = 403 = 0 = 200 = "/index.html" { = true Now run the config create the infrastructure: terraform init
terraform - -approve apply auto Awesome! All of our infrastructure is set up in AWS and now we just need to set up our GitLab runner! Configure our Runner For this part, you'll need a GitLab repository for us to work with, so create a new one before proceeding. Now that you have a repository, let's set up our runner. We're going to use a shared runner from GitLab. They're free to use up for up to 2,000 minutes of deployments per month -- and they're enabled by default. I've found that they're somewhat slow and it stinks that you're throttled at 2,000 minutes, so I usually use my own runners spun up in Kubernetes or on EC2 instances, but let's save that for another tutorial. We need to supply the runner with an AWS IAM user to use to deploy to S3. Create another terraform config with this content: {
  description default // provider region }


resource user pgp_key }

resource name user policy { : , : [
        { : , : [ ], : },
        { : , : [ , , , , ], : [ },
        { : , : , : }
    ]
}
EOF
}

resource name }

output value }

output value } variable "keybase_user" = "A keybase username to encrypt the secret key output." = "dannextlinklabs" change this} "aws" { = "us-east-1" "aws_iam_access_key" "gitlab_ci" { = "${aws_iam_user.gitlab_ci.name}" = "keybase:${var.keybase_user}" "aws_iam_user_policy" "gitlab_ci" { = "gitlab-ci-policy" = "${aws_iam_user.gitlab_ci.name}" = <<EOF "Version" "2012-10-17" "Statement" "Effect" "Allow" "Action" "s3:ListBucket" "Resource" "*" "Effect" "Allow" "Action" "s3:PutObject" "s3:PutObjectAcl" "s3:GetObject" "s3:GetObjectAcl" "s3:DeleteObject" "Resource" "arn:aws:s3:::website.example.com/*" // this needs to be set to your bucket name            ] "Effect" "Allow" "Action" "cloudfront:*" "Resource" "*" "aws_iam_user" "gitlab_ci" { = "gitlab-ci" "access_key" { = "${aws_iam_access_key.gitlab_ci.id}" "secret_access_key" { = "${aws_iam_access_key.gitlab_ci.encrypted_secret}" Make sure you set the keybase user to your own keybase user, because Terraform uses that to encrypt the IAM user's secret access key. This won't work if you don't have a Keybase account, or if you try to use my Keybase account. Run the config. terraform init
terraform - -approve apply auto The terraform config returns an access key and an encrypted secret key for this user. We need to decrypt the secret key with the command (this is why you needed to use your own keybase user). terraform output encrypted_secret | --decode | pgp decrypt base64 keybase Now that we have the access key and the secret key for our GitLab user, we just to supply these variables to our runner by adding them to the variables section in the CI/CD settings. We need to set three variables in GitLab: AWS_ACCESS_KEY_ID - the access key that Terraform returned us
AWS_SECRET_ACCESS_KEY - the access key we just decrypted
AWS_DEFAULT_REGION - us-east-1 to to secret Create our super-duper simple website We have an empty repository set up with our GitLab runner enabled, so l Super cool website! Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore
      magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo
      consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur.
      Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. < > html < > body < > h1 </ > h1 < > p </ > p </ > body </ > html Commit that and push it to the repo, and that will be all we need for the "design". Run a Deployment GitLab CI/CD is based around a file called .gitlab-ci.yml. GitLab requires that file to be located in the root of your project. Our file needs to look like this: stages:
  - - variables:
  AWS_BUCKET: website.example.com // change this if necessary
deploy_s3:
  image: python:3.6
  stage: deploy-s3
  tags:
    - - before_script:
    - script:
    - only:
    - deploy_cf:
  image: python:3.6
  stage: deploy-cf
  tags:
    - - before_script:
    - script:
    - - only:
    - deploy-s3 deploy-cf docker gce pip install awscli -q aws s3 sync . / --delete --acl public-read s3: /$AWS_BUCKET/ master docker gce pip install awscli -q export distId=$(aws cloudfront list-distributions --output=text --query ] cut -f1) 'DistributionList.Items[*].[Id, DefaultCacheBehavior.TargetOriginId' | grep "S3-$AWS_BUCKET" | read -r dist; aws cloudfront create-invalidation --distribution-id $dist --paths ; done <<< while do "/*" "$distId" master This gitlab-ci file sets up two stages: deploy-s3, and deploy-cf. The first stage uploads our website to the S3 bucket, and the second invalidates the CloudFront distribution for that bucket in order to present the new changes to our website! This simple configuration is all you need to have a complete CI/CD pipeline for your business' website. Commit and push those changes, and then check out the pipelines section under the CI/CD tab in that project. You should see a deployment running. Success! You have a working CI/CD pipeline. Now, whenever you commit code to the master branch, GitLab will auto-magically upload and distribute your changes! Daniel Slapelis is a Devops Engineer with NextLink Labs, a Pittsburgh-based Devops and full stack engineering company.

Learn How to Build a CI/CD Pipeline Using GitLab for your Website

Task description: You are given an array of linked-lists , each linked-list is sorted in ascending order. k lists Merge all the linked-lists into one sorted linked-list and return it. Example 1: Input: lists = [[1,4,5],[1,3,4],[2,6]]
Output: [1,1,2,3,4,4,5,6]
Explanation: The linked-lists are:
[
  1->4->5,
  1->3->4,
  2->6
]
merging them into one sorted list:
1->1->2->3->4->4->5->6 Solution: Before jumping to the solution to this problem let’s recall what the linked list is. A linked list is a data structure that consisted of nodes connected with each other by one(single linked list) of two(double linked list) pointers. Every node usually contains some value and pointer to the next node. The very first node is called Head and the last node is called Tail. Tail as a next pointer usually has null. In this task, we are dealing with sorted linked lists. Which means all values in every node are sorted. Every node in every list has value less or equal than value in a node which it points. To visualize it here’s an example of sorted linked list. Having an understanding of what the sorted linked list is we could solve the easier version of our problem. How would you merge 2 sorted linked lists? And the answer is - extremely simple. Compare heads of each list. Pick the node with the minimum value. Attach it to your answer and adjust the pointer to the next node in the list from which you picked out a node. Do it until one of the heads is non-equal to null. Once you reach that point you could simply attach the rest to your answer. Now we are close to solving the actual problem. From the easier task, we see that the key to the solution - is taking the node with the smallest value and attaching it to the answer by adjusting the pointer. Having an array of K sorted list heads we could iterate through it and every time pick a node with the smallest value. It would solve the problem but the time complexity is terrible. The better way will be to take every list’s head and add it to a priority queue. Priority Queue is another data structure that provides getting smallest or biggest value in O(1) constant time. And adding or remove this value in O(log n) time which is good enough for our task. Often priority queue is called a binary heap according to the way of storing elements. I could describe it in a future article. public ListNode mergeKLists(ListNode[] lists)
{
	if (lists == null || lists.length == 0)
	{
		return null;
	}

	ListNode dummy = new ListNode(0);
	ListNode prev = dummy;
	ListNode current;
	ListNode next;
	
	PriorityQueue<ListNode> minHeap = new PriorityQueue<>(
		Comparator.comparingInt(head -> head.val)
	);
	
	for (ListNode node : lists)
	{
		if (node != null)
		{
			minHeap.add(node);
		}
	}

	while (!minHeap.isEmpty())
	{
		current = minHeap.remove();

		if (current == null)
		{
			continue;
		}

		next = current.next;
		current.next = null;
		prev.next = current;
		prev = current;
		if (next != null)
		{
			minHeap.add(next);
		}
	}

	return dummy.next;
} In line 8 we create a “dummy” node, which is to be our temporary head. It will help us easily return the real head of the sorted linked lists by calling dummy.next At lines 13–15 we create a Priority Queue. We need to sort elements in it. For this purpose we provide Comparator. At lines 17–23 we add all non-null heads to the Priority Queue. At lines 25–42 we have the main while loop which contains the main logic. We update current node by removing the node with the minimum value from the top of our priority queue. Then we update next pointer by getting next node from current. We also need to update the prev pointer. You can think of the prev pointer as a pointer to the temporary tail of the linked list we are building. And last but not least if next link is not null we must push it back to the priority queue. After executing the previous steps in given example 1 we will get the state represented below. I intentionally didn’t flat it out. To show you the transition from the original state to the end state The algorithm listed above gives us the following result. The time complexity for our solution is O(N log K) where N - is the total number of nodes in all lists where K - is a number of sorted linked lists we have. The space complexity for our solution is O(N) where N - is total number of nodes to create an answer plus O(K) where K - is number of sorted linked lists we have. According to the big O notation we can omit O(K) because it could be equal or less then O(N) in terms of a number of elements. I hope this article helped you to understand the logic hidden behind this difficult task. Thanks for reading! Looking forward to your feedback. See you soon ✌ This article was first published here.

Java Algorithms: Merge k Sorted Lists (LeetCode)

Algoritmos de Java: fusionar k listas ordenadas (LeetCode)

The American Connection.

This article covers the conventional way of building full-stack applications and why manually building your backend is not always the best choice. You'll see an alternative solution for your backend needs that can be used standalone or coupled with your custom-built backend. The issues with the traditional backend The conventional approach to developing full-stack applications involves the tedious and time-consuming process of building the entire application from scratch. The backend development requires setting and configuring servers, implementing the business logic, and managing databases. Building and maintaining a complex backend from scratch would take substantial resources. So why reinvent the wheel when you can use an existing solution that you can tailor to your needs with code? But more on that later. It's important to mention that a custom-built backend might be the most appropriate solution in specific scenarios. However, in most cases, an existing solution that you can tailor to your needs through code is more than sufficient. It allows you to speed up the development process and move faster by automating the most tedious work. It also frees up resources so you can focus on business-critical tasks. Besides that, you do not need to choose one or the other. You can have the best of both worlds, as you will see later. The main pain points are as follows: complex and lengthy development process a substantial amount of resources required slow time-to-market maintenance required scalability and security are difficult Headless API solutions The alternative to custom-built backend applications are the Headless API solutions. A Headless API is an architectural design where the user interface (frontend) is decoupled from the business logic and data storage (backend). The backend exposes the data through an API. The frontend then uses the API to communicate with the backend. There are multiple advantages to this approach: The obvious one is the , since you only need to develop and focus on one part of the application - the frontend. The faster development process also enables you to reduce the time required to enter the market, which is essential in such a competitive landscape. faster development process Since you are using an existing solution for your backend, you (finances and time) that you can use on other tasks that are more critical to the business. save valuable resources Another advantage is that you have which to use since the application parts are decoupled. complete freedom when choosing frontend technologies The Headless APIs are developed and maintained by teams of developers who focus exclusively on those APIs, which means these solutions might provide than a custom-built solution. better security and scalability But now you might ask: "Where do I find these APIs?". That's where Wix Headless comes into the picture. Wix recently released their Headless APIs, enabling developers to implement Wix's robust business solutions using composable APIs and SDK. You can use them with any tech stack across different platforms and devices. Some of the current available Headless APIs are as follows: bookings - The "bookings" API enables you to integrate booking features into your app. It provides features like scheduling and managing appointments, syncing staff calendars, setting up automated reminders, and more. eCommerce - This API allows you to manage orders, inventory, shipping and finances from one central place. It provides secure payments, optimized checkouts and automated sales taxes. CMS - The CMS solution offers an API for creating and managing content. events - It allows you to build applications for hosting in-person or online events, sell tickets, manage guests, accept secure payments, and more. pricing plans - You can use this headless API to create a members-only platform and offer exclusive access. You can check all APIs . here It's important to emphasize that you do not need to choose between the Headless APIs and a custom-built backend. Instead, you can have the best of both worlds since the Headless APIs can be integrated with other internal or 3rd party services. Customize the APIs I do not believe in one-size-fits-all solutions. At one point, you will want to modify or extend the functionality through code. You can do that by using the . Wix Headless SDK You can use the SDK by installing the required packages: - the package is required to create the API client and to set up the OAuth. When you create the API client, you must provide the modules you want to use (e.g. the eCommerce Headless API). @wix/api-client - the should be replaced with the name of the Headless API you need (e.g. "@wix/ecom", "@wix/pricing-plans", "@wix/bookings" and so on). These packages return the modules you pass to the API client configuration and the ones that allow you to interact with the chosen Headless API. @wix/{api-name} api-name That's all you need to interact with the Headless APIs. Headless API Examples In this section, you will see various demos and their code. They are basic, and their sole purpose is to illustrate the basic usage of the Headless APIs. Headless CMS One of the available Headless APIs is the CMS API which provides a user-friendly dashboard for creating and managing content. Let's say we have a landing page for the following APIs: bookings eCommerce events & tickets subscriptions The app makes a request to the CMS backend to fetch information such as the title, slug, and description for each Headless API (s ). This is what the landing page looks like: ee them at the bottom of the page And here's the code that fetches the data: import Link from 'next/link'
import Cookies from 'js-cookie';
import { useEffect, useState } from 'react';

import { createClient, OAuthStrategy } from '@wix/api-client';
import { items } from '@wix/data';

const myWixClient = createClient({
  modules: { items },
  auth: OAuthStrategy({
    clientId: `<your-client-id>`,
    tokens: JSON.parse(Cookies.get('session') || null)
  })
});

export default function Examples() {
  const [examples, setExamples] = useState([]);

  async function fetchExamples() {
    const examples = await myWixClient.items.queryDataItems({ dataCollectionId: 'examples' }).ascending('orderId').find();
    setExamples(examples.items);
  }

  useEffect(() => { fetchExamples(); }, []);

  return (
    <footer>
      {examples.map((example) => (
        <Link href={example.data.slug} key={example._id}>
          <section>
            <h2>{example.data.title} <span>-&gt;</span></h2>
            <p>{example.data.description}</p>
          </section>
        </Link>
      ))}
    </footer>
  )
} The first step involves adding all the required imports at the top of the file. The next step is to create and configure the Wix API client. It requires you to specify the modules you want to use ( from the package in this case) and the for the strategy. items @wix/data clientId OAuth After that, you use the Wix client to fetch and display the data on the page. As the figure illustrates, it's a simple application. However, you can check a more complex application using the Headless CMS . here Bookings API Another API available is the bookings API, which enables you to integrate booking features into your applications. For example, you can set up flexible booking features based on location and availability, schedule or manage appointments, sync staff calendars, set up automated reminders and more. The figure below illustrates an example using the bookings API, where users can select a service and a time slot. After you choose a service and a time slot, you are redirected to a new page where you need to enter your details for the purchase. Once all the details are entered, you can add the purchase to the cart or book it straight away. In this case, I clicked the "Add to Cart" button, which took me to the cart page. You can enter a promo code or add a note on this page. Once you are done, you can click the "Checkout" button to finalize the purchase. The code is similar to the previous example in the sense that you need to create the Wix client and pass the appropriate modules. After that, it's the usual React code. import Cookies from 'js-cookie';
import { useEffect, useState } from 'react';

import { createClient, OAuthStrategy } from '@wix/api-client';
import { availabilityCalendar, services } from '@wix/bookings';
import { redirects } from '@wix/redirects';

const myWixClient = createClient({
  modules: { services, availabilityCalendar, redirects },
  auth: OAuthStrategy({
    clientId: `<your-client-id>`,
    tokens: JSON.parse(Cookies.get('session') || null)
  })
});

export default function Booking() {
  const [serviceList, setServiceList] = useState([]);
  const [availabilityEntries, setAvailabilityEntries] = useState([]);

  async function fetchServices() {
    const serviceList = await myWixClient.services.queryServices().find();
    setServiceList(serviceList.items);
  }

  async function fetchAvailability(service) {
    const today = new Date();
    const tomorrow = new Date(today);
    tomorrow.setDate(tomorrow.getDate() + 1);

    const availability = await myWixClient.availabilityCalendar.queryAvailability({
      filter: { serviceId: [service._id], startDate: today.toISOString(), endDate: tomorrow.toISOString() }
    }, { timezone: 'UTC' });
    setAvailabilityEntries(availability.availabilityEntries);
  }

  async function createRedirect(slotAvailability) {
    const redirect = await myWixClient.redirects.createRedirectSession({
      bookingsCheckout: { slotAvailability, timezone: 'UTC' },
      callbacks: { postFlowUrl: window.location.href }
    });
    window.location = redirect.redirectSession.fullUrl;
  }

  useEffect(() => { fetchServices(); }, []);

  return (
    <main>
      <div>
        <h2>Choose a Service:</h2>
        {serviceList.map((service) => {
          return <section key={service._id} onClick={() => fetchAvailability(service)}>{service.name}</section>;
        })}
      </div>
      <div>
        <h2>Choose a Slot:</h2>
        {availabilityEntries.map((entry) => {
          return <section key={entry.slot.startDate} onClick={() => createRedirect(entry)}>{new Date(entry.slot.startDate).toLocaleString()}</section>;
        })}
      </div>
    </main>
  )
} Even though the example application is quite basic, it demonstrates how valuable and powerful the headless APIs are. They provide many features out of the box without requiring you to do any backend work. Moreover, it provides a visual interface for managing the backend data. In this example, you can add, edit or remove services using the Wix dashboard. It also enables you to accept payments and manage orders. As a result, one is not required to be a developer to manage the backend. With that being said, you can check more complex applications using the Headless Bookings API here: Bookings app for a professional coach Bookings app for a personal trainer More examples This article presented two example applications to illustrate the usage of the APIs. All the examples shown in this article, and some more, are available in . Moreover, there are a handful of production-ready templates you can use as a starter. Check them out . They are more complex, and thus, they show how to build a production-ready application using these APIs. this repository here Conclusion The Headless APIs are excellent alternatives to building custom backend applications from scratch. However, you do not always have to choose between the two solutions. If you already have a custom-built backend, you can integrate these APIs into your existing backend application without requiring a total overhaul. One of the most important benefits of using an existing solution is saving valuable resources such as finances and time. These resources can then be spent on more business-critical tasks. In addition to that, these Headless APIs reduce or even eliminate the complex and lengthy development cycles. As a result, your product can reach the market sooner. The faster the time-to-market, the better. Lastly, they are built and maintained by teams of experienced developers. They are made with scalability and security in mind. That means you do not have to worry when the business gets bigger and requires more resources & better security because they handle that for you. In conclusion, whatever approach you take, you can be assured that these APIs will provide many benefits and save valuable resources. The article was originally posted on my blog - Rethink Full-Stack Development: Is a Custom Backend the Best Choice? https://youtu.be/JDode_bW9bw?embedable=true

Rethinking Full-Stack Development: Is a Custom Backend the Best Choice?

Some time ago Andrew Clark, one of the members of the React core team at that time, posted on Twitter starting with such a phrase: a thread https://twitter.com/acdlite/status/1617611126514266112?embedable=true Approximately at the same time Dan Abramov, another React core team member, wrote in a comment to a PR suggesting Vite as a replacement for . such a post CRA It felt like something serious was going on as for many developers for years the strategy to use React has been the following: Create a new app using CRA (maybe lately using ). Vite Add libraries of choice to make your life easier. PROFIT. Obviously, it wouldn’t work if you had requirements to have SSR, code-splitting, etc. But it's been a good starting point for an app and in some cases, the app might've used CRA for years as a kind of framework. So, (also, referred to as )? what are React frameworks React meta-frameworks They are the tools that are built on top of React, where a lot of pain points have been taken care of for you and they have lots of features that might improve the DX and performance of the app. In this article, we'll compare and contrast the most popular React frameworks to help you decide which one is best suited for your future project. I wanted to start from the list mentioned in another post by Andrew Clark: https://twitter.com/acdlite/status/1617611129282527232?embedable=true 1. Next.js The first one on the list is Next.js (though Andrew might be a little biased as he recently joined , the cloud-based platform for deploying and scaling web applications behind Next.js). Vercel The framework has 4,125,745 weekly downloads. The initial version was released in October 2016, making it around 7 years old as of 2023. Some main features of Next.js are: Server-side rendering (SSR) and Static Site Generation (SSG): Next.js supports server-side rendering and static site generation out-of-the-box, allowing developers to render pages on the server-side for better performance and SEO, or generate static sites with dynamic data fetching. To do that you simply need to export either export the function or the one. getServerSideProps getStaticProps : Each file inside your pages/ directory will be automatically code split into its own JavaScript bundle during the build step, meaning for you that every page will require less code to load. Automatic code splitting Built-in CSS support: Next.js CSS modules, Sass, PostCSS, and CSS-in-JS libraries. supports Zero Configuration: Next.js comes with built-in configurations that handle the most common web development use cases, allowing developers to focus on building their app logic rather than setting up tooling. TypeScript support: Next.js natively TypeScript, which offers strong typing, easier debugging, and better code quality. supports Image optimization: Next.js images automatically, reducing their size without any loss in image quality. optimizes : Next.js provides API routes out-of-the-box, making it easy to create the backend functionality for your application in case you need it. API Routes : Next.js supports file-based routing, which means developers can create new pages and routes for them by simply adding a new file to the pages directory. also supports nested routes and dynamic route segments. File-based routing The concept of pages Incremental Static Regeneration (ISR): Next.js supports ISR, which allows for pages to be re-generated incrementally in the background, providing the most up-to-date content while still maintaining fast page load times. : Next.js has native integration with Vercel, a cloud-based platform for deploying static and serverless applications, which allows for seamless deployment and scaling of your application. Also, it's free for personal or non-commercial projects. Though you can deploy your app anywhere where Node.js is supported as basically a Next.js app is still a Node.js app. Vercel Integration Preview Mode: Next.js supports the , which allows content editors to preview changes in real-time before publishing. preview mode Internationalization: Next.js has built-in support for , which allows developers to create multi-language pages easily. internationalization (i18n) Rust-based tooling: From to , Rust-based tools are used in Next.js heavily to provide developers with faster DX. Next.js Compiler Turbopack Client-side navigation: Next.js provides client-side navigation using the , which provides a smooth and seamless user experience. Next.js Link component The subjective cons are: Learning curve: I mean are great, but you need to study them in order to be able to build stuff. the docs Some things are opinionated, e.g. file-based routing, etc. It's not exactly bad, but there is a chance you'll want to do something differently, but won't be able to do so. You'll need Node.js support on your server to get the most out of it. Though it's possible to export your app as so that you can host it on any web server that can serve static assets. static HTML/CSS/JS All in all, Next.js provides you with everything you might need to build a web app. Obviously, the main focus is websites/"googleable" web apps, but . you can build a client-only app (aka SPA) as well 2. Remix The second framework in the list is Remix. Remix was introduced in December 2020 by the team at Remix Software, led by Michael Jackson and Ryan Florence. It is a relatively new framework, but it has gained a lot of attention and popularity among developers due to its unique approach to server-side rendering and data management compared to other React frameworks. The main features are: Server-side rendering (SSR): to be fair everything in Remix is SSR, so there is no choice in how you want to render your app. It's part of . the philosophy Incremental hydration: Remix uses incremental hydration, which allows for a faster and smoother user experience by updating only the necessary parts of the page when changes occur. Automatic code splitting: Remix automatically splits code into smaller chunks for better performance and faster load times. File-based routing: Similar to Next.js Remix allows developers to create pages by simply adding a new file to the pages directory, making it easy to organize and manage pages. Additionally, are supported. nested routes Full-stack data management: Remix provides a unified approach to data management, allowing developers to manage both client-side and server-side data in a single API. Pre-rendering and rehydration hooks: Remix provides hooks for pre-rendering and rehydration, allowing developers to control the rendering and hydration of their applications. : Remix provides a simple and flexible API for working with forms, including built-in validation and error handling. Forms and validation -based tooling, meaning everything is fast. esbuild : Basically, stacks are sets of all the configs you need to start developing and to be able to deploy your app to your favorite cloud provider. Stacks : Remix supports many of the CSS frameworks out of the box, though it has its limitations as the team suggests you either use route-based styles or Tailwind. Built-in CSS support TypeScript support: Remix natively TypeScript. supports The philosophy in general is to embrace web standards, not fight them. Cons: Learning curve: the same thing that applies to Next.js. You need to read lots of to get comfortable with your Remix project. docs Opinionated: to be fair the philosophy of Remix reminded me of something from the times when we had to use PHP / Ruby on Rails, etc. This is not bad, it's just different. It's easy to make a mistake when both server-side and client-side code is in one place: https://remix.run/docs/en/1.14.3/guides/constraints#rendering-with-browser-only-apis You'll need Node.js support on your server. The Remix team has been actively promoting their product. E.g. is a comparison between Next.js and Remix (where Remix is slightly better in the end, of course). In my opinion, it is a great tool, but its approaches are a bit different from the approaches the Front End world got used to. here 3. Gatsby The next framework was not mentioned in the post by Andrew Clark, yet I personally wanted to include it here. It was introduced in 2015 by Kyle Mathews. Initially, Gatsby posed as a static website generator, now it's way more than that. Here are some of the features of Gatsby: : Gatsby is historically known as a static site generator enhanced with React Hydration. But starting with Gatsby 4, you can choose alternative rendering options ( or ) in addition to static site generation (SSG) — on a per-page basis. Rendering options Deferred Static generation (DSG) SSR Built-in : Gatsby includes a built-in GraphQL data layer, making it easy to fetch and manage data from multiple sources, including APIs, CMSs, and databases. GraphQL : Gatsby makes it easy to build progressive web apps (PWAs) that work offline and can be installed on mobile devices. Progressive web apps (PWAs) Image optimization: Gatsby built-in tools for optimizing and processing images, including support for lazy loading and responsive images. provides : Gatsby automatically splits code into smaller chunks for faster load times and better performance. Code splitting Plugins and themes: Gatsby supports , making it easy to extend and customize the framework. plugins and themes SEO optimization: Gatsby includes built-in support for SEO optimization, including automatic generation of meta tags, sitemaps, and social media sharing images. Content mesh: Gatsby provides a content mesh feature that enables developers to combine data from multiple sources, including headless CMSs, APIs, and databases. : Gatsby allows developers to build incrementally, which means that only the necessary parts of the site are rebuilt when changes are made, making the build process faster. Incremental builds Integration with , which allows you to use , Live Preview, , and host your app build with Gatsby. Gatsby Cloud Serverless functions CMS Preview Using SSG you can avoid having Node.js on the server which means there are fewer things that can get broken on production. [File-based routing] Gatsby supports allowing you to configure routes the way you need. file-based routing The Cons: Learning curve: again, it's not just React anymore and reading docs is a crucial part of your success with Gatsby. Opinionated: even after ~2 years of using Gatsby in production I'm still not sure about several aspects of Gatsby's philosophy, e.g. the GraphQL data layer is a little bit questionable for me. Though if you want, you can query data . without GraphQL You'll need Node.js support on your server in case you want to use any of the rendering options apart from SSG. If you're interested to hear about my personal experience with Gatsby, (in Russian). In general, I think that Gatsby is very nice to build a modern web app. Recently, Gatsby , a cloud computing platform, which means that in the future we can expect a deeper integration with them. here's my talk about it has joined Netlify 4. Expo The last framework from the list is Expo, which is a framework, which means it does a different job, but still is a meta framework within the React ecosystem. Plus, it's possible to develop web apps using it. React Native The main features are: Cross-platform development: Expo developers to build and deploy mobile applications for iOS, Android, and the web from a single codebase, using React Native. allows Built-in components and libraries: Expo includes a variety of pre-built components and libraries, including UI components, navigation, and authentication, that make it easier to build mobile apps. Live reloading: Expo provides live reloading just like a normal React dev environment nowadays, which is rare. Push notifications: Expo includes built-in for push notifications, making it easy to send notifications to users of your app. support Secure storage: Expo provides for sensitive data, including user credentials and authentication tokens. secure storage Sensible defaults: Expo sets sensible defaults for common settings and configurations, making it easier for developers to get started quickly. Easy deployment: Expo provides a simple and easy , allowing developers to deploy their apps to the App Store and Google Play Store with minimal effort. deployment process OTA updates: Expo supports over-the-air (OTA) updates (the process is called ), allowing developers to push updates to their apps without requiring users to download a new version from the app store. EAS Update Expo Snack: is an online code editor that allows developers to quickly prototype and share their code with others. Expo Snack Third-party libraries: Expo a wide range of third-party libraries and plugins, making it easy to add additional functionality to your app. supports Easy debugging: Expo provides for easy debugging of your mobile app, including debugging on real devices and simulators. tools . TypeScript support Different styling options, including . Styled Components You can even use in your Expo project to be able to share code between mobile and the web. Next.js Limitations to consider when using Expo.js: Limited access to native APIs: Expo provides a set of pre-built APIs that allow you to access common features such as the camera or push notifications, but if you need to access a more specialized or custom API, you may need to eject from Expo and use React Native directly. Limited control over the build process: With Expo, much of the build process is handled by the Expo servers, which can limit your ability to customize or optimize your app's build configuration. You may also have to wait for Expo to update its own dependencies before you can update your app's dependencies. App size and performance: While Expo does offer some optimizations to reduce the size of your app, it may still be larger than a native app, which can impact performance and user experience. Dependency on Expo servers: Your app may rely on the Expo servers to function properly, which means that if those servers experience downtime or are discontinued, your app may stop working. Conclusion In this article, we've considered several modern React frameworks. All of them are great choices and all are powerful frameworks that provide a lot of helpful features and tools. When choosing between them, it's essential to consider your project's specific needs and requirements, and your personal preferences. In my opinion, both Next.js and Gatsby are very similar nowadays and provide developers with a similar toolkit, despite beginning their journey from different starting points (Gatsby – as a static website generator and Next.js as an SSR app framework). Gatsby may appeal to you by the GraphQL data layer, the Gatsby Cloud features, and the plugin system. Next.js may be a better fit for you if you want to decide yourself how to query data, want to use the blazing-fast Rust tooling, and prefer the Vercel infrastructure. If you want to explore an approach to building React apps that embrace web standards, but is a bit different from other frameworks, Remix might be a better fit. Finally, if you're building a mobile application, Expo is a great choice that provides a lot of helpful tools and integrations.

Popular React Framework Choices to Develop React Apps in 2023 

is an open-source framework created by (formerly ZEIT). It is built on top of React and provides an out-of-the-box solution for (SSR) of React components. Furthermore, it supports (SSG), which can help us to build superfast and user-friendly websites in no time. Although a relatively young framework, it has a good which complements well with existing i18n libraries. In the following chapters, you will find out how to set up internationalization in your Next.js app. Next.js Vercel server-side rendering static site generation foundation for internationalization Create a new Next.js project First, let's create a new Next.js project with the CLI tool. create-next-app npx create-next-app nextjs-i18n-example Add React Intl dependency As we mentioned earlier, the Next.js works well with existing i18n libraries ( , , , and similar). In this tutorial, we will use the . react-intl lingui next-intl react-intl cd nextjs-i18n-example
npm i react-intl Add config for internationalized routing Translations and routing are two main pillars of internationalization. The previously added library is going to handle translations and formatting. When it comes to routing, Next.js has for that. This built-in support offers two options, sub-path routing, and domain routing. In this tutorial, we will use sub-path routing as it is less complex and more common for average websites. For that, let's update the file with the config. react-intl built-in support next.config.js i18n /** @type {import('next').NextConfig} */
const nextConfig = {
  reactStrictMode: true,
  i18n: {
    // The locales you want to support in your app
    locales: ["en", "fr"],
    // The default locale you want to be used when visiting a non-locale prefixed path e.g. `/hello`
    defaultLocale: "en",
  },
};

module.exports = nextConfig; The internationalized routing is available since . Next.js 10 Create localization files The next important thing is to add localization files. For that purpose, let's create a directory. Within it, add two JSON files: and . These files are going to hold translations for English and French, respectively. Below, you can see the project structure after adding the mentioned files. lang en.json fr.json nextjs-i18n-example
|-- lang
|   |-- en.json
|   |-- fr.json
|-- pages
|   |-- api
|   |-- _app.js
|   |-- index.js
|   |-- ...
|-- public
|-- ...
|-- package.json
|-- package-lock.json Afterward, fill in localization files with messages that we will use later. The file: en.json {
  "page.home.head.title": "Next.js i18n example",
  "page.home.head.meta.description": "Next.js i18n example - English",
  "page.home.title": "Welcome to <b>Next.js i18n tutorial</b>",
  "page.home.description": "You are currently viewing the homepage in English 🚀"
} The file: fr.json {
  "page.home.head.title": "Next.js i18n exemple",
  "page.home.head.meta.description": "Next.js i18n exemple - Français",
  "page.home.title": "Bienvenue à <b>Next.js i18n didacticiel</b>",
  "page.home.description": "Vous consultez actuellement la page d'accueil en Français 🚀"
} Configure react-intl in Next.js project Internationalized routing and localization files are just the first part of the task. The second part is setting up the library. Below, you can see what changes have been made in the file. react-intl _app.js import { useRouter } from "next/router";
import { IntlProvider } from "react-intl";

import en from "../lang/en.json";
import fr from "../lang/fr.json";

import "../styles/globals.css";

const messages = {
  en,
  fr,
};

function MyApp({ Component, pageProps }) {
  const { locale } = useRouter();

  return (
    <IntlProvider locale={locale} messages={messages[locale]}>
      <Component {...pageProps} />
    </IntlProvider>
  );
}

export default MyApp; Adapt pages for i18n We did most of the work. The last step is to put all this together. Therefore, we are going to update the file under the pages directory. Below, you can find two approaches for accessing the localization messages, imperative and declarative. We've already covered , , and similar in . index.js these two ways of usage formatting options another post The file: index.js import Head from "next/head";
import Link from "next/link";
import { useRouter } from "next/router";
import { FormattedMessage, useIntl } from "react-intl";

import styles from "../styles/Home.module.css";

export default function Home(props) {
  const { locales } = useRouter();

  const intl = useIntl();

  const title = intl.formatMessage({ id: "page.home.head.title" });
  const description = intl.formatMessage({ id: "page.home.head.meta.description" });

  return (
    <div className={styles.container}>
      <Head>
        <title>{title}</title>
        <meta name="description" content={description} />
        <link rel="icon" href="/favicon.ico" />

        {/* Add hreflang links */}
        <link rel="alternate" href="http://example.com" hrefLang="x-default" />
        <link rel="alternate" href="http://example.com" hrefLang="en" />
        <link rel="alternate" href="http://example.com/fr" hrefLang="fr" />
      </Head>

      <header>
        <div className={styles.languages}>
          {[...locales].sort().map((locale) => (
            <Link key={locale} href="/" locale={locale}>
              {locale}
            </Link>
          ))}
        </div>
      </header>

      <main className={styles.main}>
        <h1 className={styles.title}>
          <FormattedMessage id="page.home.title" values={{ b: (chunks) => <b>{chunks}</b> }} />
        </h1>

        <p className={styles.description}>
          <FormattedMessage id="page.home.description" />
        </p>
      </main>
    </div>
  );
} Congratulations! 🎉 You have successfully set up internationalization in your Next.js project. More details and examples you can find in the . original post All code samples used in this article are available on the . GitHub repo I hope you found this guide useful. Feel free to give me feedback in the comments. Also Published Here

NEXTLINK LABS

nextlinklabs.com

-- employees

Since n.d.

COMPANY RANKING

NEXTLINK LABS

EVERGREEN INDEX #7774

Representing this company? Click here to claim and customize this page!

NextLink Labs WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!

NEXTLINK LABS

nextlinklabs.com

-- employees

Since n.d.

COMPANY RANKING

NEXTLINK LABS

EVERGREEN INDEX #7774

RELATED COMPANIESRANK

STORIES ABOUT NEXTLINK LABS

Representing this company? Click here to claim and customize this page!

NextLink Labs WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!